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[57] ABSTRACT 

Apparatus, and accompanying methods for use therein, for 
an ISDN LAN modem that is suited for small user environ- 
ments and which contains an internal ISDN router having a 
self-contained network hub for inter-connecting multiple 
network devices, such as workstations, to each other through 
a local area network and for permitting each of those devices 
to each gain access through the router to any one of a number 
of different remote networks. The LAN modem communi- 
cates network failure messages to a host workstation con- 
nected to the LAN by intercepting and responding to various 
DNS (domain name system) messages issued by that work- 
station and intended for a remote DNS server. Specifically, 
the LAN modem supplies its own network (IP) address in 
response to these messages, thus assuming a role of both a 
remote DNS server and a remote web server in order to 
implement a mechanism through which a fault-specific web 
page can be dynamically constructed and downloaded to the 
workstation for subsequent display, through a browser 
executing thereat. The page, once rendered, provides a 
specific message pertinent to the failure. 
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Wizstat . htm s~\ qa 

<!D0CTYPB HTML PUBLIC D -/ /IETF/ /DTD HTML//KN°> llO. C.cL 

<html> 

2200 

<head> j 

<meta http-equiv= "Content-Type" 

contents 0 text /html; charset=iso-8859-l"> 

<meta name = " GENERATOR a content = "Microsoft FrontPage 2.0"> 

<title>SPID Wizard</ title > 

</head> 

<body bgcolor= D #00FFFF"> 
REFRESH. * — 2210 2215 

, x 

<p align="center"xfont color="#0000FF° Bize=°6 B >_TlTLE_</fontx/p> 

.PICTURE 1_ - — 2220 2225 

, — * , 

<p align= B center"xfont size= B 4 a xBtrong>JTEXTl_</strongx/fontx/p> 

<p align=°center D ><font size= 0 4 D ><8trong> 
_PICTURE2_- — 2230i 
_TEXT2_ « 2235 

_PICTURE2_ 2230 2 

</8trongx/fontx/p> 

<p align=°center l, >tnb8p;</p> 

„BUTT0N_ 2240 

</body> 
</html> 
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FIG. 25 



2500 

Wizstat.htm ^/ 
<!D0CTYPE HTML PUBLIC B -//IETF//DTD HTML/ /EN" > 
<html> 

<head> 

<meta http-equiv= D Content-Type n 

content = ° text /html ; charset=iso- 8859-1 a > 

<meta name= ■ GENERATOR" content^ "Microsoft FrontPage 2.0°> 

<title>SPID wizard</title> 

</head> 

<body bgcolor="#00FFFF"> 

<p align= n center" >< font color="#0000FF D size= D 6">ISP Wizard</fontx/p> 

<p align= n center n xfont 8ize= D 4 D ><strong>Logging on to the ISP failed! 
< / strongx / f ont >< /p> 

<p align= D center°xfont size="4"xstrong> 
<lmg src= p ballred.gif" width="13" height* " 13 °> 

Please verify your Telephone Number, User ID, Password and try again. 
<ine src= n ballred.gif° width="13" helght="13"> 
</ strongx / font x /p> 

<p align= n center">fcnbsp;</p> 

<form method= "POST" > <!--webbot bot="SaveResults D u-file="_private/fo 
na_results.txt" s-format="TEXT/CSV° s-label-f ields=°TRUE" — xp align= 
■center" xinput type=° submit" value= D Try Again" name= D Bl"> <input type 
</body> 
</html> 
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struct 

[ 



Data Datat[95] = 



BOLLET_D_GIF 
MANUALjra 

wspidhto 

bullet_h_gif 
bdllet_p_gu 
bullet_s_gif 
bullet_t_gif 

CHANGE_HTO 
V0ICB_HTM l 
NORMM0DE_HTM J 
BRIOFFQ_HTM 
CRKDITS_H I M 

ispwiz^htm. 
dcallprm_h™, 
hsdm_h™, 
hcpafms_h™ 

HISPHTH 
HLANHTH, 
HMAHJT__HTM, 
HPCKTi_HIM, 
HPRTVATB_HTH, 
H SERY ICB-HlMj 
HSETPASS_HTM i 
STATS_HTH, 
HAINTENA^ETM, 

waitline_etm 
waitspidsth 
nrmode_htm j 
iwabort_htm 
calljoinj™ 

WANLHTM, 

IXlMJPG; 

IX1MCJPG, 
IXIS.JPG, 
IX1SWJPG, 
IX1IWLJPG 
IX1WWJPG 

ixip_jpg 
cghtroljpg 
wizsta^htm, 

SWABORT_HTM J 
LOCKEELHTlfj 
LOGOWPG 
N0TIMPL_HTM 

ALERT_GIF 
BALLGRE_GIF 
BALLKED_GIF 
FAILED_HTM 
STAT3_HTM 
IX3S_JPG 
HPCPARKS_SEM 
STAT4_HM 
STAT5_HTM 
PRIVNBT_HM 
CALLCTRL_HTM 
ISP„HM 
PSWDSET_HTM 
WRPSWD_HTW 
SPSELECT_HTM 
PCSELBCT_HTM 
PC HTM 



B0IiLET_D_GIF" } , 
MANUAL_ffIH 1 } , 
WSPID_HTO"}, 

STAT1_HTM»}/ 
KJLLET_H__GIF" } , 
EULLET_P_GIF - } # 
BOLLET_S_GIF 1 > , 
BOLLET_T_GIF 9 ), 
CHANGE_Hra* } , 
■VOICE_HTH-), 
N0RMM0DE_HTO' } , 
BRIOFFCLHTM"}/ 
CREDITS_HTM B } , 
ISPWIZ_HTM"}, 
DCALLPRM_Hra'} # 
HSDNHTM"}, 
HCPARMS_HTM"}/ 
HISP_HTM" } , 
HLAN_HTM" } , 
HMAIOT_HTM - } , 
HPCEL_HTM" } , 
HPRIYATB_HM B }# 
HSKRVICE_HM" } , 
HSETPASS_ffM-) f 
STATS_HTM a } , 
MAINTENAHTM-h 
WAITIiINK_HTM 1 } , 
WAITSPID_H!IM - } f 
NRMO0E_HTM > ># 
IWABCRTHBT}, 
CALLJOIN_HTM"} # 
WAN_HTM">, 
IX1M_JPG"}, 

IXlMC_JPG"}r 

IX1S_JFG"}, 

mswjPG-}, 

IX1IW_JPG" } , 

mww_jPG"}, 

IX1P_JPG"}, 

O0OTROL_JPG">/ 

WIZSTAT_Hra">f 

SWABORT_HMM, 

LOCKKD_HTM" } , 

L0GOl_JPG"}, 

N0TZMPL_HTM a } , 

ALERT_GIF« ) , 
BALLGRB_GIF"}, 
BALLRED_GIF" } , 
FAILED_HTO" } , 
STAT3_HTM B ), 
IX3S_JPG"), 
HPCPARHS_HTO - }, 
STAT4_HTH" } , 
STAT5_HTM" } , 
FRIVNET_HTM"), 
CALLCTRL_ffIM - } , 
ISP_ffM"}, 
PSWDSET_HTM"), 

SPSELECT_HTM W }, 
PCSELECT_HTM" } , 

vc_wm m ), 
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WAITFIRMjnM 
HMANOAL_HTM 
HVOICB__HTM 

coixauiTa.ffm 
zsracoNLKOf 

SKTPSWD_HTM 
MQDB!N0T_HTM 
ISDNCGK_HTH 
OFFLN0K_HTO 
DEFAULT_H1M 
IX3CC_JPG 
IX3I_JPG 
IX3LC_JPG 
IX3SP_JPG 
C0NT_JPG 
MAINPAGE_HTM 
EWTER_HTM 

hmparms_h™ 
frbott0mhtm 

H PCSEL _HM, 
FRCONTEN^HTO 
LAH_HTM 
IXMM_JPG 
PSWDOK_HTM 
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spidok_h™ 

onlineq_htm 
callmadee_h™ 
cal ldisc_ hto, 

RESETOK_H , M 
STAT2_HTM 1 
FRMAH?_Hra 
(char *0 



■WAITPIHM_HM"}, 
•HMANUAL_HTM-} # 
■HVOICE_HTO"}# 
■CONGRATD_HTO B } , 
■ISDNC0N_HTO"}, 
■ SETPSWD JBTM * } , 

•ISDNCOKHTM"}, 
■OFFI«CMC_HTM"}# 
■DBFAULTJHM" } , 

■mcc_jPG"}, 

■IX3I_JPG"} f 

■DC3ljC_JPG") f 

■DOSP_JPG"), 

■C0NT_JPG"} f 

•MAINPAGB_HTM" } , 

•HfIER_HTH" } , 

•HMPARHSHTM"}* 

•FRBOTT0M_HTM-}, 

*HPC SKTi_H ra B } , 

■FRCONTENjrM*}, 

■LRN_HM B }# 

■DOW_JPG"}, 

■PSWDOK_HTO«} # 

■PARAMOKJTIM" } , 

"SPIDQK_HTM* } , 

"GKLINBQ_HTO! a } , 

■CALIJ4ADG_H1M" } , 

"CALLDISC_HTM" } , 

■RJ5SETGK_HTM* } , 

■STAT2_HM"L 

■FRMAIN.HTM"}, 

■NULL"} 
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extern char IX3LC_JPG[]; 
extern char IX3SP_JP6[]; 
extern char C0NT_JF6[]; 
extern char M MMP AGB_HM [ ] ; 
extern char HfrER_HTM[]; 
extern char EHPARKS_HTM [ ] ; 
extern char FRBOTTOHJEEMIJ; 
extern char HPCS EL_H IM[1; 
extern char FRC0NTEELH7H[]; 
extern char LAN_HTH[]; 
extern char IXMM_JPG[]; 
extern char PSWDOKHIMl]; 
extern char PARAW)K_HTM[] ; 
extern char SPIDOKEEM_JPG[]; 
extern char 0NLINEQ_HIM[] ; 
extern char CALLMADB_HTO[ ] ; 
extern char CALLDISC^HTO [ ] ; 
extern char RKSETOK_HTM[J ; 
extern char STAT2_HTM [ ] ; 
extern char FHMM2I_HTM[]; 



extern struct Data 
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char *DataPtr; 
char *Name; 
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APPARATUS AND METHODS FOR USE* 
THEREIN FOR AN ISDN LAN MODEM 
THAT DISPLAYS FAULT INFORMATION TO 
LOCAL HOSTS THROUGH INTERCEPTION 
OF HOST DNS REQUEST MESSAGES 

BACKGROUND OF THE DISCLOSURE 

1. Field of the Invention 

The invention relates to apparatus, and accompanying 
methods for use therein, for an ISDN LAN modem (or an 
aspect thereof) that is particularly, though not exclusively, 
suited for small user environments and which contains an 
internal ISDN router having a self-contained network hub 
for inter-connecting multiple network devices, such as 
workstations, to each other through a local area network 
(LAN) and for permitting each of those devices to gain 
access through the router to any one of a number of different 
remote networks. 

2. Description of the Prior Art 

Over the past decade, personal computer (PC) usage has 
increased substantially to the point where currently PCs 
have diffused into many aspects of a business organization. 
Coincident with this phenomena, a desire has increasingly 
arisen, certainly in a workplace environment, among com- 
puter users in a common organization, such as a business 
establishment, to readily share computer files. This desire, 
particularly when fueled by historically decreasing costs of 
network equipment, has led to an expanding number of 
network installations throughout the business community to 
facilitate file sharing and electronic communication among 
not only users in a common organization, but also with users 
at other organizations and locations. Moreover, as these 
costs of increasingly sophisticated PCs and network equip- 
ment continue to fall, networked computer usage is pen- 
etrating increasingly smaller organizations as the expected 
benefits to those organizations, such as expanded 
productivity, outweigh the costs associated therewith. 

Moreover, the trend of increasing PC usage is not con- 
fined to business. Home usage of PCs is also rising though 
currently penetration of PCs into homes is still considerably 
less than that in the business community. Nevertheless, PC 
applications exist that address various needs of a family, 
from, e.g., traditional productivity tools, such as word pro- 
cessing for, e.g., home office use, to education, entertain- 
ment and to Internet access. Given this, today, it is increas- 
ingly common for a family to possess several PCs. For 
example, for a typical family of two spouses and two 
children of school age, each spouse may require his(her) 
own PC for business use, such as for job-related endeavors, 
while each child may have one PC or share a common PC, 
purchased for all children in the family, for, e.g., educational 
use, such as running teaching programs of one sort or 
another, Internet access, or entertainment. 

If current cost and technology trends continue, PC usage 
should increasingly proliferate throughout businesses and 
families to a point of becoming rather ubiquitous and 
inter-connected, Le., at least ideally and at some time in the 
future where most people will possess their own PC and 
where such PCs will become increasingly inter-networked 
with each other. 

However, a significant obstacle to increasing PC usage 
and inter-networking has been the continued difficulty many 
individuals face when installing and configuring a PC, let 
alone connecting the PC to a wide area network (WAN), 
such as the Internet, or even implementing a simple local 
area network (LAN). 
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For many Individuals/ specifically those inexperienced 
with PCs, the task of just installing and configuring a PC 
itself is so daunting, particularly for so-called IBM compat- 
ible PCs, that the task often negates their desire to purchase 

5 a PC. To counter this, PC manufacturers have made and 
continue to make significant strides over the past few years, 
such as through incorporating so-called "Plug and Play" 
hardware and using compatible pre-loaded operating 
systems, such as the "WINDOWS 95" operating system 

J0 (WINDOWS 95 is a trademark of the Microsoft Corporation 
of Redmond, Wash.), to automatically detect system hard- 
ware and self-configure the PC, as well as to simplify 
subsequent PC use and maintenance. Unfortunately, the 
same can not be said for computer networks. 

}S Installing hardware for a very simple computer network 
for a small number of users (henceforth referred to as a 
"workgroup") is relatively straightforward — typically 
encompassing installing a multi-port network hub and a 
network interface card the latter into each PC to be net- 

2Q worked in the workgroup and running interconnecting 
cables therebetween. However, properly configuring con- 
ventional network hardware and associated software in each 
of the PCs is a rather tedious task — one that often frustrates 
even an experienced user. Consequently, many users desir- 

25 ing to network their computers, even for a simple network, 
have relegated the task of installing and properly configuring 
their networks, including both hardware and software 
components, to properly trained service organizations or 
consultants but at a considerable expense relative to the cost 

30 of the equipment. While a relatively large organization can 
afford to incur such expenses, small organizations and 
families can not. Accordingly, while many small business 
users and even home users could significantly benefit from 
networking their computers together as workgroups — such 

35 as through file sharing and electronic communication, the 
difficulty and expense associated therewith has effectively 
limited the penetration of computer networks into these 
environments. 

Therefore, a need exists in the art for a computer nel- 

40 working device that not only implements a LAN, which 
permits computers to be networked together in, e.g., a 
workgroup, but also significantly simplifies and expedites 
network configuration. Such a device should ease the burden 
placed on the user as much as possible, preferably to a point 

45 of automatically adapting itself, without user intervention, to 
its current network environment. As yet, no such device 
exists in the art. 

Furthermore and quite apart from increasing proliferation 
of PCs, in recent years, a number of domestic and foreign 

50 telephone companies have begun offering Integrated Service 
Digital Network (ISDN) services to their customers. ISDN 
provides an integrated voice and data network that offers 
both increased bandwidth and significant flexibility over 
traditional analog telephone services. Inasmuch as sub- 

55 scriber charges for ISDN access are decreasing — with the 
decrease being rather noticeable for some telephone 
companies, demand for ISDN service and equipment is 
rising appreciably. Demand is particularly strong and grow- 
ing for those subscribers who seek cost-effective high speed 

60 access to a WAN such as, e.g., the Internet, and/or other 
computer networks. 

In particular, a basic rate (so-called "2B+D" service) 
ISDN interface provides higher speed bandwidth than both 
traditional analog, modem-based dial-up access modalities 

65 and comparably priced switched digital services. Each 
so-called B ("bearer") channel, which carries subscriber 
voice and/or data, provides 64 Kbits/second of bandwidth; 
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while a D ("data") channel, which carries signaling and " Moreover, it' is increasingly common to find multiple 

control information, provides 16 Kbits/second of bandwidth. users on the same network who simultaneously desire to 

For the bandwidth delivered, an ISDN line is significantly connect to the Internet through different network service 

less expensive than a private leased line that supplies the providers, e.g., one user may desire to connect to one 

same bandwidth across the three channels. Furthermore, 5 internet service provider (ISP) at the same time another user 

ISDN, being a digital end-to-end service, provides digital wants to connect to a different ISP. Unfortunately, currently 

transmission channels that tend to be more accurate and available ISDN routers can not accommodate simultaneous 

reliable, from a standpoint of error rates and dropped ISDN connections by multiple PCs to different ISPs; such 

connections, than are conventional analog telephone con- routers are limited to accommodating only one connection to 

necuons^ In addiuon, ISDN service provides rapid connect w Qne , sp al a dme Moreover> lhese routers are unable to 

times which, in turn, provide faster support for those LAN , , , - „ c , r 

, ..V • 1 *• 1 i_ 1 * ai/axt control access, on a per PC basis, to any one 01 a number of 

protocols that require relatively short latency across WAN , w ~~*» *~ J . 

** „ multiple accounts across different network service provid- 

connections. r r 

Starting a few years ago, various networking and com- eis " 
miinications equipment manufacturers have been offering Hence, given the increasing availability of economical 
relatively inexpensive ISDN terminal adapters, more com- 15 ISDN connections and advantages associated with the use 
monly and rather loosely referred to as "ISDN modems" thereof, the computer networking device needed in the art 
(though these adapters do not contain a traditional analog should not only implement a LAN that serves a workgroup 
modulator-demodulator as occurs in a conventional analog but also should implement an ISDN router to provide 
modem), and other ISDN-based network devices, such as simultaneous high-speed access for the LAN through a 
routers, for subscriber end-use. Such a modem, also generi- 20 single ISDN connection to multiple service providers, such 
cally referred to as "data circuit terminating equipment" as, e.g., different ISPs. Moreover, such a device should be 
(DCE), once connected to an ISDN connection and a serial easy to configure, without a need for any external software, 
port on a subscriber's PC, permits that subscriber to connect ^ to reduce its price, dispense with a need for any serial 
higher) computer to, e.g., an Internet service provider and or other port lsscd f or mma i configuration, 
communicate at speeds approximately two to four times 25 a . 1 , , . ... , , 
greater than throughTcor^ntional analog modem. The Advantageously, such a device which as yet does not 
computer so connected becomes so-called "data terminal "ist mthe shou i d no , 1 ^ substaaUaUy eliminate user 
equipment" (DTE). While the availability of ISDN modems ^^n and significantly -reduce time and caste associated 
is clearly not the sole cause underlying the growth in ISDN ^ establishing, configuring and using a LAN for a work- 
usage, it, when combined with decreasing rates for ISDN 30 S^P f weU 35 with connecting each PC therein to a remote 

service, is certainly a large and growing factor. ***** P rtmdcr > but «*° mclC3 ^ thc of ^ 

IT r , . l, ,o^*t j * . LANs in small businesses and among home users to the 

Unfortunately, currently available ISDN devices, such as fc . , - - . 

. * j ^, 7 ^_ _. eventual benefit of each. 

routers, which connect a network, e.g., an Ethernet network, 

to a single ISDN connection are rather cumbersome and SUMMARY OF THE INVENTION 

tedious to configure. In that regard, such a router typically 35 

contains an RS-232 serial port to which a PC is connected The present invention overcomes the deficiencies in the 

in order to initially configure the router. During art and satisfies these needs by providing an ISDN LAN 

configuration, a user at the PC, typically executing a pro- modem that contains an ISDN router, with an internal 

prietary application provided by the manufacturer of the multi-port hub to implement a LAN (local are network), that 

router, assigns suitable network parameters, including an IP 40 automatically adapts itself to a current network environment 

address and a subnet mask, to the router. Until these param- of a workstation connected thereto and then permits 

eters are loaded into the router, the router is simply unable browser-based configuration, and accommodates several 

to communicate over the network to any PC connected modalities of network communication not heretofore pos- 

thereto. I>termining the correct value of these parameters siWe m a conventional router. 

and then completing the configuration, with all the other 45 With respect to configuration, the LAN modem can 

salient information, proved to be a rather tedious process. receive configuration information directly from a works ta- 

Furthermore, not only did the user incur a burden of install- tion connected to the LAN, and specifically through, 

ing software on the PC used to configure the router, but also illustratively, a web browser (or other appropriate TCP/IP 

the price of the router needed to reflect an added cost of the application, such as Telnet) executing on that workstation, 

serial port, which during the life of the router is usually used 50 advantageously without any need for any additional serial 

just once for initial configuration. (or other) port on either the LAN modem or the workstation. 

In addition, in the event of a network fault or other Specifically, in accordance with specific teachings of the 
condition that affects a connection to a remote LAN or WAN present invention, once the workstation is connected to the 
and/or server thereon, conventional routers do not indicate hub and the browser begins executing on the workstation, 
the specific nature of that fault to any local client connected 55 the LAN modem automatically adapts itself to the current 
to the router. This, in turn, relegates a user at that client to network environment of the workstation. To do so, the LAN 
rely on an error message, in those instances when it is modem will detect the Ethernet address of that workstation 
provided by the network, that is often rather cryptic at best through packets transmitted by the Workstation, determine 
and more often simply not provided at all. In the latter the IP address of that workstation (either through dynamic 
situation, the user simply waits in basically total ignorance 60 assignment or by static address of the workstation from an 
of the fault, i.e., the fault occurs but the user receives no ARP (address resolution protocol packet)), and then, if the 
indication of it on e.g., his(her) browser. Not only is the user workstation is using static addressing, set its own IP address 
annoyed by this type of fault handling, but also the user is and subnet mask such that the LAN modem and the work- 
forced to wait, owing to a lack of information which leads station are on the same subnet. Once this occurs, the LAN 
to an expectation (which later proves to be unwarranted) that 65 modem and the workstation are then able to communicate 
the fault will resolve itself, which can be rather time- over the network through the web browser. The LAN 
consuming and frustrating. modem will then intercept any request issued by the work- 
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station to fetch a web page and, through its own internal web 
server, will generate and download to the workstation, a 
default home page through which the user can commence 
configuring the LAN modem. Once configuration 
commences, the web server will then step the user through 
a succession of displayed web pages through which the user 
will be queried to enter salient configuration data. The web 
server will then extract this data from responses received 
from the user and then store this data, for subsequent use, in 
a shared database within the LAN modem. 

Furthermore, the LAN modem provides additional 
modalities of network communication through use of an 
inventive multi-tiered routing hierarchy, which permits 
bi-directional translation between many individual private 
IP addresses and one shared public IP address. 

Specifically, the LAN modem assigns a private IP address 
to each workstation that connects to the LAN. The LAN 
modem translates the individual private IP address of each 
of the workstations to a single public address assigned, e.g., 
either statically or dynamically, to the LAN modem by a 
network service provider, e.g., an Internet service provider 
(ISP), by accessing a source-based routing table and a host 
list which collectively associate the private source IP address 
of a particular workstation on the LAN and a network ID for 
the service provider to which that workstation is ultimately 
connected through the LAN modem. The LAN modem also 
translates source and destination port number fields, as 
needed. This IP address and port number translation assures 
uniqueness of a set of source/destination IP addresses, 
protocol ID and source/destination port numbers in packets 
that flow between unique client/server applications and 
which pass through the LAN modem so as to provide 
unambiguous routing in the LAN modem between all the 
workstations connected to the LAN modem and associated 
remote servers. 

Consequently, through such translation, then as far as the 
ISP is concerned, all packet traffic involving the 
workstations, by virtue of their common, though shared, 
public IP address, appears to emanate from or be directed to 
a single user. Appropriate account information, such as user 
identification and password data, for the shared account is 
stored within the shared database in the LAN modem. 
Through this information, the LAN modem transparently 
establishes the connection between the workstations and the 
ISP without prompting any of the actual users therefor for 
appropriate account information. As a result of employing 
this inventive translated addressing technique, the LAN 
modem distributes (effectively de-multiplexing) individual 
packets emanating over a single ISDN connection from the 
ISP to the proper workstations on the LAN, and routes (i.e., 
effectively multiplexes) outgoing packets, from all such 
workstations having differing private IP addresses, into a 
common packet stream over a single shared packet connec- 
tion to that ISP for subsequent transport over the remote 
network. Advantageously, by permitting multiple users to 
share a single ISP account, use of our inventive technique is 
likely to significantly reduce collective network access 
charges over what these users would otherwise incur if, as 
conventionally occurs, they were to gain network access 
through separate user accounts. 

Furthermore, through use of the inventive hierarchical 
routing scheme, toe LAN modem can simultaneously route 
packet traffic between multiple workstations on the LAN 
and different corresponding ISPs through different ISDN 
connections simultaneously existing between the LAN 
modem and those providers. In this regard, the LAN modem 
accommodates connections to several different user- 
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definable network service providers^ e.g., ISPs, by storing 
appropriate information for each such provider in a shared 
database, such as user account and password information, as 
well as network identification including network IP address, 
5 domain names and remote DNS server addresses, and 
employing this information to define the appropriate con- 
nections and properly route packets accordingly over these 
connections. 

As a feature of the present invention, the LAN modem 

10 advantageously contains internal co-operating DHCP 
(dynamic host control protocol) and DNS (domain name 
system) servers that are integrated with routing and call 
management processes, all utilizing data stored within the 
shared database. 

15 Use of the internal DNS server provides local name-to- 
address resolution such that, for user convenience and 
simplicity, each workstation on the LAN can be addressed in 
terms of its machine name rather than its IP address. 
Furthermore, the DNS server, by using the same shared 

20 database as does the DHCP server, operates transparently of 
any user to acquire machine names of all the workstations 
connected to the LAN and then provide suitable machine 
name to IP address resolution, as needed, for all communi- 
cation between the LAN modem and these workstations as 

25 well as between any pair of workstations themselves. In 
addition, the DNS server given a DNS query, will determine, 
based on the source of the query, i.e., which specific work- 
station generated it, and the destination to which the query 
is directed (e.g., another host on the LAN as identified by the 

30 machine name of the host, the LAN modem itself or a 
remote network), the DNS server to which the query is to be 
routed and will then route the query accordingly to that 
server. As such, the LAN modem hides from a host the 
selection of the DNS server that will be used in a given 

35 instance and hence significantly simplifies the use of the 
DNS in each workstation connected to the LAN modem. In 
addition, the DHCP server provides the IP address, subnet 
mask and gateway and DNS server addresses to the local 
workstations, thereby eliminating any need for a user to 

40 manually configure and administer these items. 
Furthermore, any workstation is always assigned the same 
IP address from the DHCP server, rather than having its IP 
address change from session to session, as would normally 
occur with dynamic IP addressing. Consequently, a user 

45 profile associated with each workstation can be easily main- 
tained and identified using its host IP address, and the 
number of workstations that are simultaneously allowed to 
use the LAN modem can be very easily controlled. 

As another feature of the present invention, the LAN 

50 modem assures the integrity, to a substantial degree, of 
executing program code stored within volatile memory, e.g., 
DRAM (dynamic random access memory), within the LAN 
modem, thereby advantageously preventing to a significant 
extent code corruption and improper operation of the LAN 

55 modem. Flash memory, by virtue of its non-volatility, stores 
executable program code for the LAN modem. Upon a 
system reset, the executable code is written into DRAM, 
which provides markedly faster access time over the flash 
memory, from which the code is then executed. 

60 Specifically, while the LAN modem is idling, a preempt- 
able background process executes with, e.g., a low execution 
priority, to continually compare the entire executable pro- 
gram code stored in the DRAM, on a location-by-location, 
basis, with that stored in the flash memory. In the event a 

65 discrepancy is detected, the contents of a location in flash 
memory are copied to a corresponding location in the 
DRAM to eliminate the discrepancy, thereby maintaining 
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the integrity of the executable code stored in the DRAM. 
Integrity of the code stored in the flash memory is assured 
by restricting any change in the mode of the flash memory 
from read-only to read/write through use of a key-based 
software lock. 

As an additional feature of the present invention, the LAN 
modem contains an internal web server that, in addition to 
storing full web pages, constructs web pages in real-time 
from a predefined stored web page template by selectively 
inserting, e.g., event-specific, code segments therein. 
Illustratively, this insertion occurs by substituting such a 
segments) for a corresponding so-called "placeholders)" 
that appears in the template. These segments can represent 
dialog boxes, graphics, predefined textual messages or, 
generically speaking, any object, whether implemented 
through HTML or otherwise, that is to be, e.g., selectively 
presented to a user either for display and/or to solicit a 
response, such as an item of data or a selection among a list 
of predefined data values, from the user. Since relatively few 
full web pages are stored, memory requirements to store the 
underlying data to support the web server advantageously 
become rather modest Illustratively, and in the context of 
the LAN modem, these web pages are used to query a user 
situated at any workstation on the LAN to enter information 
needed to configure the LAN modem, as well as to display 
a specific nature and cause, if known, of a detected fault 
condition so that an affected user situated at any such 
workstation can take appropriate action. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The teachings of the present invention can be readily 
understood by considering the following detailed descrip- 
tion in conjunction with the accompanying drawings, in 
which: 

FIG. 1 depicts an overall high-level block diagram of 
inventive LAN modem 300 in its typical environment of 
use; 

FIGS. 2A-2C each depicts a different illustrative mode of 
operation which inventive LAN modem 300, shown in FIG. 
1, can provide; 

FIG. 3 depicts a hardware block diagram of inventive 
LAN modem 300 shown in FIG. 1; 

FIG. 4A depicts an overall block diagram of software that 
is executed by central processing unit (CPU) 330, shown in 
FIG. 3, situated within the inventive LAN modem; 

FIG. 4B depicts an architectural block diagram of soft- 
ware 400 contained within application software 4020 shown 
in FIG. 4A that, among other aspects, implements the 
various modes of operation of the LAN modem shown in 
FIGS. 2A-2C; 

FIG. 5 depicts interaction, in terms of predominant inter- 
process communications, that occurs within software 400 
shown in FIG. 4B for setting up an ISDN call based on traffic 
on the local area network. (LAN); 

FIG. 6 depicts interaction, in terms of predominant inter- 
process communications, that occurs within software 400 
shown in FIG. 4B for setting up an ISDN call based on a 
DNS (domain name system) request from a workstation 
(host) on the LAN; 

FIG. 7 depicts interaction, in terms of predominant inter- 
process communications, thai occurs within software 400 
shown in FIG. 4B for processing an incoming ISDN call to 
the LAN modem; 

FIG. 8 depicts interaction, in terms of predominant inter- 
process communications, that occurs within software 400 
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shown in FIG. 4B for disconnecting an ISDN call as a result 
of an idle timeout condition; 

FIG. 9 depicts the correct alignment of the drawing sheets 
for FIGS. 9A-9C; 
5 FIGS. 9A-9C collectively depict a flowchart of Initial 
Configuration procedure 900 performed by CPU 330; 

FIG. 10 depicts the inventive source-based routing archi- 
tecture used in the LAN modem; 
10 FIG. U depicts a flowchart of Primary Router procedure 
1100 shown in FIG. 10 and performed by CPU 330; 

FIG. 12 depicts the correct alignment of the drawing 
sheets for FIGS. 12A-12D; 

FIGS. 12A-12D collectively depict a flowchart of Sec- 
15 ondary Router procedure 1200 also shown in FIG. 10 and 
performed by CPU 330; 

FIG. 13 A depicts the structure of host list 1300 including 
its constituent data fields and their initial entries, contained 
within database 416 stored within flash memory 376 shown 
20 in FIG. 3; 

FIG. 13B depicts the structure of network service pro- 
vider list 1350 including its constituent data fields also 
contained within database 416 stored in flash memory 376 
^ shown in FIG. 3; 

FIG. 13C depicts the structure of Destination-Based Rout- 
ing Table 432, including its initial values, stored within 
DRAM 372 shown in FIG. 3; 

FIG. 13D depicts the structure of Source-Based Routing 
30 Table 446 which is also stored within DRAM 372 shown in 
FIG. 3; 

FIG. 14 depicts a flowchart of DHCP Induced IP Address 
Request procedure 1400 performed by CPU 330; 

FIG. 15 depicts the correct alignment of the drawing 
35 sheets for FIGS. 15A-15D; 

FIGS. 15A-15D collectively depict a flowchart of DNS 
Induced IP Address Request procedure 1500 that is also 
performed by CPU 330; 
40 FIG. 16 depicts a flowchart of Firmware Upgrade (FU) 
process 402 shown in FIG. 4B that is also performed by CPU 
330; 

FIG. 17 depicts a flowchart of Firmware Assurance Man- 
ager process 1700 that is contained within application pro- 
45 grams 4020 shown in FIG. 4A and is executed therein as 
background (lowest priority) application 4030; 

FIG. 18 depicts a high-level block diagram of web server 
412, shown in FIG. 4B, and certain of its associated 
processes,; 

50 FIG. 19 depicts a flowchart of Static Page Processing 
operation 1830 that is performed by web server 412 shown 
in FIG. 18; 

FIG. 20 depicts a flowchart of Dynamic Page Formation 
operation 1840 that is also performed by web server 412 
55 shown in FIG. 18; 

FIG. 21 depicts a flowchart of Post Processing operation 
1850 that is also performed by web server 412 shown in FIG. 
18; 

^ FIG. 22 depicts code 2200 for an illustrative inventive 
web page template, and specifically one employed in con- 
junction with an ISP Wizard used in the LAN modem; 

FIG. 23 depicts a page, as would be rendered on a 
workstation display, in response to HTML code 2200 shown 
65 in FIG. 22; 

FIG. 24 depicts, in block diagram form, inventive process 
2400 for forming a web page from a web page template and 
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page components, and illustratively for a web page used in readily appreciate how to use our invention with any of a 

conjunction with the ISP Wizard; wide range of differing types of computer networks and to 

FIG. 25 depicts HTML code 2500 for a specific web page modif y * e inventive teachings, as rccessary, to conform to 

that results from use of process 2400 and template HTML ^ requirements of the specific network bemg used, as well 

code 2200 for a specific event, e.g. a failure to establish a 5 as to wrfoim « °* ^ ™ 0 ^* ^ 

TV . . ■ • swcr>\ of ISDN interface, or different connection modality, to a 

connection to an Internet service provider (ISP); remote network. 

FIG. 26 depicts a page, as would be rendered on a a. Overall Network Environment 

workstation display, in response to HTML code 2500 shown piQ. i depicts an overall high-level block diagram of the 

in FIG. 25; ^ inventive local area network (LAN) modem 300 in its 

FIG. 27 depicts a sequence of three pages 2710, as would typical environment of use. Though LAN modem 300 does 

be rendered on a workstation display, to portray a progress not contain a traditional analog modulator-demodulator as 

bar and which result from three corresponding HTML code occurs in a conventional analog modem, for ease of 

segments 2720, all of which are dynamically constructed in reference, this device will nevertheless be referred to as a 

accordance with the present invention; modem" inasmuch as it provides the general func- 

n _ , . „ , „ _ _ lb tionality associated with a modem of connecting a worksta- 

FIG. 28 depicts a flowchart of File Creation process 2800 tion tQ m extemal network, though here through 

that creates a common file of a web page template and ^ ISDN ratncr man ^ PQTS (plain old telephone 

associated web page components in accordance with the service), connection. 

present invention; As illustrated, LAN modem 300 inter-connects a group of 

FIG. 29 depicts data structure 3000, stored within reposi- 20 workstations (also referred to herein as "hosts") 10, ifius- 

tory 1860, containing templates and web page components tratively here four individual workstations (typically per- 

as produced through execution of File Creation process 2800 sonal computers — PCs) 10 fl , 10 b7 10 c and 10 d > in an Ethernet 

shown in FIG. 28; local area network. To implement the LAN, LAN modem 

FIG. 30 depicts the correct alignment of the drawing 300 contains ISDN router 305 which itself contains an 

sheets for FIGS 30A-30B* 25 internal, here illustratively lOMb/second lOBaseT, Ethernet 

FIGS. 30A-30B collectively depict source code for data J* which connects through ports 15, specifically 15„, 

structure 3000 containing, in accordance with the present 15^15 e and 15^ to workstaUons 10. 

. - , . c ... The router establishes an ISDN connection through BRI 

inventive teachings, various entries each having, for either Tr ^ KT , ... . , , , , , 

*ii * »• u . i , -lu u ~ ISDN connection 40 and public switched telephone network 

an illustrative web page template or an illustrative web page ^ rk0rr _ rv , . ; t ^ , ^ A - n 

f a a- „ a 30 (PSTN) 50 to appropriate remote networks 60 and/or 70, 

component, a pointer and a corresponding name; and v , . * . . . . 

such as the Internet or a private network, accessible through 

FIG. 31 depicts actual object code for a document array, a ^^^^ ^cc provider, or a remote LAN, such as 

e.g., FRMAIN_HTMD, containing a corresponding Ulus- m office network . [n^uch as router 305, as discussed in 

trative predefined web page component, as stored in struc- detail ^low, can accommodate, in one of its operational 

ture 3000. 35 modalities (as discussed below in conjunction with FIG. 

To facilitate understanding, identical reference numerals 2B), two simultaneous connections, over different B chan- 

have been used, where possible, to designate identical ne is (here shown as Bj and Bj) in a common BRI ISDN 

elements that are common to various figures. connection, to two different external networks, these con- 

TYFTATI fd nF^lPTfON oections are symbolized by leads 55 and 58 connecting 

UblAlLbU Dh^LKlKllUlN 40 remo te networks 60 and 70 over channels B 1 and B 2 , 

After considering the following description, those skilled respectively, 
in the art will clearly realize that the teachings of the present Apart from routing ISDN packet traffic, via PSTN 50, 
invention can be readily utilized in substantially any ISDN between any of workstations 10 and a remote network(s), 
data circuit terminating equipment (DCE) which interfaces LAN modem 300, specifically ISDN router 305 therein, can 
an ISDN line to nearly any form of computer network, 45 also accommodate two analog telephone devices 20 (here 
regardless of the type of network. In that regard, the ISDN illustratively shown as facsimile machine 20a and telephone 
line can be, e.g., a basic rate (2B+D) interface (BRI) or a 20 fr and also denoted as analog telephone devices 1 and 2, 
primary rate (23B+D or 30B+D) interface. Moreover, the respectively) appropriately interfaced, via ports 25, to ana- 
network can be illustratively Ethernet, Token Ring, asyn- log lines 25 A and 25 2 . In that regard, the LAN modem can 
chronous transfer mode (ATM), frame relay or other type of 50 bi-directionally route digitized voice traffic on either or both 
network — with the actual network modality being irrelevant B-channels of ISDN connection 40 between PSTN 50, and 
to the present invention. In addition, these teachings are also specifically, to either one or simultaneously to both of analog 
applicable across a wide variety of remote network connec- telephone devices 20, respectively, 
tion modalities, not just ISDN. In that regard these modali- B. Modalities of Use of Inventive LAN Modem 
ties can illustratively range from, e.g., analog telephone 55 Inventive LAN modem 300 can function in a variety of 
connections using conventional modems, through high- different; network modalities, as shown, e.g., in FIGS, 
speed digital connections such as ATM or frame relay. 2A-2C. Generally speaking, in accordance with our 
Inasmuch as Ethernet networks are the predominant network invention, LAN modem 300 can: operate in a true routing 
architecture used in inter-connecting personal computers mode using either dynamic or static IP (internet protocol) 
(PCs) in a local area network, and particularly those for 60 addressing for all the workstations on the LAN; provide two 
implementing as workgroups, to simplify the discussion, the simultaneous connections, as discussed above, for two dif- 
invention will be discussed in that context. Moreover, since ferent workstations on the LAN, over separate B-channels of 
a basic rale type ISDN interface is often used to provide a a common ISDN connection, to different corresponding 
remote network connection for individual subscribers and remote networks; and provide simultaneous access for any 
small businesses, we will also discuss our invention in the 65 or all workstations on the LAN to a common service 
context of its use with such an interface. Clearly, after provider, such as an internet service provider (ISP), through 
considering this discussion, those skilled in the art will a single user account 
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FIG. 2A depicts LAN modem 300 operating -as a trotr devices) connected to the LAN. None of these private 

router, using illustratively static IP addressing. Here, work- addresses is ever routed beyond the LAN. As the user logs 

stations 10^ 10^ 10 c and I0 d have all been assigned static onto the LAN and establishes a connection through LAN 

IP addresses, illustratively 222.123.4.1, 222.123.4.2, modem 300 to his(her) ISP, that ISP will dynamically assign 

222 123.4.3 and 222.123.4.4, respectively, with LAN 5 an IP address to that user. The dynamic public IP addresses 

modem 300 carrying static IP address 222.123.4.7. Given * c ^ and ^6 are e g. 210.7.12.1 and 

these addresses, all the workstations and the LAN modem 234.12.63.15, respectively. Each of the dynamic IP 

are on the same statically assigned subnet. Consequently, addresses will be stored within the LAN modem 

T Axr j tru\ -ii • i . *u ¥ am *ul* (particularly within a shared database therein as discussed 

LAN modem 300 will examine packets on the LAN that Jf . * t ... . . . . ^ 

., . . T f VT . , . „ below m detail). As incoming packets containing these 

carry an Ethernet address of the LAN modem and emanating 10 ^ ^ ^zlcZedby the ISPs, over the 

from any of the workstations to determine, from the desti- differeDt B chann els, to LAN modem 300, the LAN modem, 

nation IP address of the packet, whether that packet is m ^ translate the dynamic public IP address 

destined for a local application, (as discussed below) execut- contained in each such packet to the private IP address of the 

ing on the LAN modem, or is to be routed off the LAN to corresponding workstation and route the packet, but con- 

a remote network. If the destination address indicates a 15 taining the translated address as the destination IP address, 

different network, here illustratively remote network 60, or to the LAN. Similarly, for packets appearing on the LAN 

a different subnet, then the LAN modem establishes an which, based on their destination IP addresses, are to be 

ISDN connection through PSTN 50 to a service provider for routed by the LAN modem to either of the ISPs, the LAN 

illustratively remote network 60 and then routes the packet modem, in essence, will translate the source IP address in 

accordingly to that remote network. LAN modem 300 also 20 each of these packets from the private IP address into the 

examines all packets incoming from remote network 60 and appropriate public dynamic IP address of the associated 

routes all such packets destined for any of the workstations workstation, substitute the translated IP address for the 

on the static subnet to the LAN. private IP address in each such packet, and then route that 

In establishing the ISDN connection, the LAN modem packet accordingly to the proper remote network. Though 

can be configured to utilize multi-link PPP (point-to-point 25 this scenario has been described as using dynamic IP 

protocol) in establishing the connection. Assuming this addressing for both of the workstations, i.e., with addresses 

protocol is supported by the service provider, then, based on being dynamically assigned by both the remote networks 

the amount of packet traffic which is to be carried over the involved and the LAN modem, one or both of the worksta- 

connection at any time and hence the required transmission tions can alternatively be statically addressed using fixed 

bandwidth therefor, either one or, as shown, both B channels 30 public IP addresses. Moreover, though this example depicts 

(Bj and for a total available bandwidth of 128 Kbits/ merely one workstation connected to each ISP, the LAN 

second) will be used to carry this traffic, via ISDN lines 40 modem, as will be clear in conjunction with the scenario 

and 58, among LAN modem 300, PSTN 50 and the service depicted in FIG. 2C, can share a common connection to an 

provider (not specifically shown) for remote network 60. ISP across multiple workstations. 

Through use of multi-link PI)P, the number of B channels 35 In addition, as noted above and depicted in FIG. 2C, LAN 

that carry this traffic at any one time will dynamically vary modem 300 can provide simultaneous access for any or all 

between one and two based on traffic loading then occurring. workstations in the LAN to a common service provider, such 

LAN modem 300 can also be configured to dynamically as a single ISP, through a single account. Here, assume that 

assign an available IP address within the subnet assigned to within a workgroup, illustratively User 7 , User 9 and User 10 

the LAN modem (hence providing dynamic IP addressing) 40 respectively stationed at workstations 10^ 10,- and 10 y all 

to each of the workstations as a corresponding user, i.e., desire to access, e.g., the Internet through a single user 

User,, User^ User 3 or User 4 , logs onto the LAN network. account at a common ISP, here symbolized by remote 

Alternatively, as noted above and depicted in FIG. 2B, network 60. 
LAN modem 300 can provide two simultaneous connections As each of the three users logs on to the LAN through 
for two different workstations in the LAN, over separate 45 his(her) corresponding workstation, LAN modem 300 
B -channels (each providing 64 Kbits/second of bandwidth) dynamically assigns an available private IP address to the 
of a common ISDN connection, to different corresponding corresponding workstation for that user. Accordingly, work- 
remote networks. Here, assume that within a workgroup, stations 10^, 10 ; and 10, are assigned illustrative private IP 
User 5 and User 6 stationed at respective workstations 10, and addresses 192.168.1.2, 192.168.1.4 and 192.168.15; with 
10f have different user accounts at different ISPs (Internet 50 LAN modem 300 itself having private IP address 
service providers), here symbolized by remote networks 60 192.168.1.1. While the first of these three users initiates a 
and 70, respectively, and desire to access the Internet during connection to remote network 60, via the common ISP, the 
the same time through these different ISPs. ISP dynamically assigns an IP address, illustratively 

Illustratively, for User 5 and User 6 , LAN modem 300 will 198.6.1.1, to that workstation. IP address translation will 

establish a single B-channel connection, as symbolized by 55 occur as described above. In many instances, though not 

line 58, over B-channel B„ to remote network 60, and as specifically shown here, both port number fields (as dis- 

symbolized by line 55, over B-channel B^ to remote net- cussed below) and IP addresses will be translated. Such IP 

work 70, respectively. address and port number translation, when required, assure 

Furthermore, in this scenario, as each user logs onto the proper uniqueness between a set of source/destination IP 

LAN through a corresponding workstation (10, or lOy), 60 addresses, protocol IDs and source/destination port numbers 

LAN modem 300 dynamically assigns an available private in packets flowing between unique client/server applications 

IP address to the workstation for that user. Accordingly, and which pass through the LAN modem. This, in turn, 

workstations 10, and X0 f are assigned private IP addresses provides unambiguous routing in the LAN modem between 

192.168.1.2 and 192.168.1.4, respectively; with LAN all the workstations connected to the LAN modem and 

modem 300 having private IP address 192.168.1.1. The 65 associated remote servers. 

LAN modem maintains a list of private IP addresses avail- Specifically, for incoming packets traversing from remote 

able for local use by workstations (or other networked network 60 to workstation 10^ via the LAN modem, LAN 
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modem 300 will translate the dynamic public IPdesnnautnr* reader understanding, the software will then be described 

address in each such packet into the corresponding private IP first with reference to FIGS. 4A and 4B, in terms of its 

address, substitute the latter for the former in each such overall architecture; followed by a description, then with 

packet and then transmit the resulting packet onto the LAN, references to FIGS. 5-8, of the interaction that occurs 

from which workstation 10^ will receive that packet. For 5 among several software processes for implementing various 

outgoing packets from this workstation appearing on the operations performed by the inventive LAN modem; and 

LAN and destined for remote network 60, LAN modem will concluding with a description, with reference to various 

translate the private IP address in that packet, as its source remaining figures, of the implementation, typically invorv- 

address, to the corresponding public IP address, substitute ing several of the software processes shown in FIGS. 4A and 

the latter for the former in the packet and then route the 10 4B, of various aspects of the inventive LAN modem, 

resulting packet via ISDN connection 40 to remote network 1. Hardware 

60. As the other two users each establishes a separate FIG. 3 depicts a block diagram of inventive LAN modem 
connection through their workstations 10, and 10,, via the 300. As shown, the LAN modem contains ISDN router 305. 
LAN modem, to the same ISP, LAN modem 300, using our ISDN router 305 contains ISDN interface 310, central 
inventive source-based routing technique — which is 15 processing unit (CPU) 330; analog line interfaces 350 con- 
described in detail below, will recognize the same network tain ing identical analog line interfaces 350 1 and 350 2 ; 
address of the ISP in packets emanating from these two memory 370; and serial EPROM (electrically programmable 
workstations, translate their differing private IP addresses to read only memory) and watchdog timer 380; all of which are 
the same public IP address associated with workstation 10^. interconnected through bus 390. In addition, the ISDN 
Through our inventive addressing technique, all packet 20 router also contains display latch 335 and Ethernet hub 340. 
traffic, as symbolized by dashed lines, for these three work- Furthermore, the LAN modem also contains conventional 
stations will share a single common public IP address, here power supply, combinatorial logic and clocking circuits 
illustratively 198.6.1.1, and traverse a common ISDN which, for simplicity, have all been intentionally omitted 
connection, here symbolized by lines 40 and 58, among the from the figure. 

LAN modem, PSTN 50 and remote network 60. LAN 25 Memory 370, which illustratively comprises dynamic 
modem 300 will provide suitable IP address translation, as random access memory (DRAM) 372 and flash memory 
discussed above, between the individual private IP addresses 376, stores software instructions-— the salient software pro- 
of each of the three workstations and the single public cesses and modules being discussed in detail below, con- 
address dynamically assigned to first workstation by the ISP. stants and temporary data all used by the CPU. The flash 
Consequently, as far as the ISP is concerned, all packet 30 memory provides non-volatile program and constant stor- 
traffic involving the three workstations will appear, by virtue age. Inasmuch as DRAM provides faster access than flash 
of their common, though shared, public IP address, to memory, during a power-on boot phase, the boot program is 
emanate from or be directed to a single user. Appropriate executed to load the executable program code into DRAM, 
account information, such as user identification and pass- from which the program code is then executed. As will be 
word data, for the shared account is stored within LAN 35 discussed in detail below, to prevent errant execution, while 
modem 300 such that the LAN modem can transparently the LAN modem is idling, a preemptable background pro- 
establish the connection between the workstations) and the cess executes with, e.g., a lowest execution priority 
ISP without prompting any of the actual users therefor. As a (specifically Firmware Assurance Manager process 1700 
result of employing this inventive addressing technique which wfll be discussed below in conjunction with FIG. 4A 
(utilizing IP address and where required, port number 40 and in detail in conjunction with FIG. 17) to continually 
translation), individual packets emanating over a single compare the entire executable program stored in the DRAM, 
ISDN connection from the ISP for remote network 60 can be on a location-by-location basis, with that stored in flash 
distributed on the LAN to the proper workstation and to a memory to assure integrity of the former. In the event a 
proper application or process executing thereon; while out- discrepancy is detected, the contents of a location in the flash 
going packets, from all such workstations, initially having 45 memory are copied to a corresponding location in the 
differing private IP addresses can be subsequently routed DRAM to eliminate the discrepancy. A portion of the flash 
into a common packet stream over a single shared packet memory is also used to store and provide access to so-called 
connection to that ISP for subsequent transport over remote "Stac" data compression tables for use in implementing 
network 60. Advantageously, by permitting multiple users, B-channel data compression. Inasmuch as so-called "Stac" 
here, e.g., three such users, to share a single ISP account — 50 compression itself is well-known, we will not discuss the 
which generally incurs a flat-rate charge regardless of actual Stac compression algorithm itself in any further detail, 
connection time, use of our inventive technique is likely to Furthermore, the DRAM also stores source- and destination- 
significantly reduce collective network access charges by a based routing tables; these tables are discussed in consider- 
factor of, e.g., % over what these users would otherwise able detail below. Integrity of the program code stored in the 
incur if, as conventionally occurs, they were to gain network 55 flash memory is assured, as described in detail below, 
access through three separate user accounts. Here too, through a key-based software lock which strictly limits those 
though this scenario has been described as using dynamic IP instances where write-access is permitted to the flash 
addressing of the workstations, i.e., with addresses being memory. 

dynamically assigned by the LAN modem and the address of CPU 330 is implemented by illustratively a 68EN302 

the LAN modem itself being dynamically assigned by the 60 central processing unit (CPU) platform which is currently 

ISP, one or more of the workstations or the LAN modem can commercially available, as a single integrated circuit, from 

alternatively be statically addressed using fixed public IP Motorola Corporation of Schaumberg, 111. This platform 

addresses. provides, inter alia, a core 68000-type microprocessor, inter- 

C. Detailed Discussion of Inventive LAN Modem nal RAM, various timers, a reduced instruction set (RISC) 

With the above in mind, the discussion will proceed to 65 controller and an Ethernet controller (all of which is not 

describe, with reference to FIG. 3, the hardware of LAN explicitly shown). CPU 300 also contains three HDLCs 

modem 300 in detail, followed by the software. To simplify (high-level data link controllers — also not specifically 
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shown), each of which is allocated by the CPU, under therefrom during initialization of the LAN modem. The 

program control, to a different one of the 64 Kbits/second watchdog timer is periodically reset, under program control, 

B-dbannels or the 16 Kbits/second D-channel to control data by the CPU. However, should the timer not be reset in the 

transmission and reception thereover. These HDLCs along event of a failure condition, the timer will time-out and 

with ISDN interface 310 collectively implement, in 5 generate a suitable pulse to reset and re-initialize the CEIU 

hardware, an ISDN BR1, specifically all ISDN layer 1 and hence the LAN modem, and thus attempt to return the 

functionality. ISDN interface 310 is conventional and con- LAN modem to its proper operation, 

tains ISDN transceiver 312 and analog front end 314, the ISDN router 305 also contains 10 Mbit/second lObaseT 

latter containing a transformer, common mode choke, tran- Ethernet hub 340, which is illustratively implemented by a 

sient suppressor, ferrite beads, diode bridge and an ISDN 10 single integrated circuit, to provide an internal LAN with 

DC termination circuit — all of which are not specifically external Ethernet ports 15. This hub is directly connected to 

shown . In essence, the termination circuit provides a polarity CPU 330 and is controlled by the Ethernet controller internal 

insensitive dc termination for loop-sealing current and a to the CPU. Hub 340 provides four Ethernet ports 15, 

recognizable signature for mechanized loop testing systems. specifically Ethernet ports 15 a , 15^, 1S C and 15^ to which 

Interface 310, specifically transceiver 312 therein, 15 four separate workstations 10 (see FIG. 1) (or other suitable 

bi-directionally passes, i.e., receives and transmits, incom- network devices) can be connected. Though in this 

ing and outgoing B and D-channel packets between analog embodiment, hub 340 is sized to accommodate four Ethernet 

front end 314 and, via bus 390, CPU 330. The output of devices, larger hubs can be used to accommodate additional 

interface 310 is connected, via leads 40, to an ISDN BRI Ethernet ports, as desired. The routing tables, host lists and 

subscriber line. Display latch 335, which is connected to 20 network service provider lists as well as other aspects of the 

CPU 330, is set by the CPU, under program control, to software, all being described in detail below, would need to 

appropriately energize suitable front panel indicators, spe- be suitably modified to accommodate an increased number 

cifically light emitting diodes (LEDs), on the LAN modem of workstations; however, the manner of doing so would be 

to indicate its current operational status. readily apparent to those skilled in the art 

Analog line interfaces 350, which contain identical inter- 25 2. Software Architecture 
faces 350 a and 350 2 , are used to interface LAN modem 300 Given the above hardware description of LAN modem 
to analog device ports 25, and particularly to two standard 300, we will now focus on describing the software. The 
analog telephone devices, via output leads 25 x and 25 2 (each reader should now refer to FIG. 4A which depicts a high- 
having a tip and ring pair "T/R"), each terminating in a level diagram of the overall software that executes in the 
conventional RJ-11 jack (not specifically shown). Each 30 LAN modem. 

interface, of which interface 350, is typical and will be As shown, this software, stored in memory 370, contains 

specifically discussed, interfaces LAN modem 300, partial- operating system (O/S) 4010 and application programs 

larly ISDN router 305 therein, to a corresponding one of two 4020. Inasmuch as details of the operating system are not 

analog telephone devices, connected via leads 25 1 and 25 2 . relevant to the present invention, all such details will be 

In particular, interface 350 2 contains codec (coder-decoder) 35 omitted from the ensuing discussion. 

352, dual-tone multi-frequency (DTMF) receiver 354, sub- Application programs 4020 are formed of a collection of 

scriber loop interface circuit (SLIQ 356 and analog front application processes and modules, most of which execute 

end 358. Codec 352 converts B -channel digital data appear- with relatively high priority — and are grouped as application 

ing on bus 390 and destined for, e.g., an analog telephone software 400 shown in FIG. 4A, but with one, Firmware 

device (such as, e.g., a telephone or facsimile machine) 40 Assurance Manager process 1700, that is fully preemptable 

connected to leads 25 2 , into a conventional analog telephony and executes at a relatively low, e.g., lowest, priority level, 

form. Analog front end 358 contains a conventional analog Hence, for all practical purposes and to facilitate 

hybrid circuit, not specifically shown, which injects appro- understanding, Firmware Assurance Manager process 1700 

priate analog tones into tip and ring lines of an analog is shown as a task within background tasks 4030. As noted 

telephone device port, and provides echo cancellation and 45 above and as will be discussed in detail below, to prevent 

battery feed functions. DTMF receiver 354 collects DTMF errant program execution, whenever the LAN modem, spe- 

tones appearing on the analog line, e.g., line 25 1 , connected cifically the CPU therein, is to enter an idle state, e.g., not 

to the interface and applies the tones to SL1C 356. The SLIC transferring data from one portion of the LAN modem to 

provides conventional analog telephony (POTS — plain old another, process 1700 will then execute to continually check 

telephone service) functions of: DC battery feed, over- 50 the integrity of the executable program copy then residing 

voltage, ringing, two-wire supervision, two-to-four wire within DRAM 372 (which is actually executed by CPU 

hybrid, and test functions, as well as current limiting,, 330 — see FIG. 3) by comparing that copy, on a location- 

on-hook transmission, tip-open and loop-current protection. by- location basis, with the executable version then stored in 

Each HDLC controller has an associated software- flash memory 376. Should process 1700, shown in FIG. 4A, 

implemented device driver. Under an event-driven software- 55 detect any unexpected discrepancy between these two copies 

implemented supervisor, CPU 330, in view of current of the executable program code, then, at each memory 

resource requests and then available hardware resources, location in the DRAM at which such a discrepancy exists, 

assigns and binds a given controller and its associated driver process 1700 will copy the contents of the corresponding 

to a particular hardware resource in order to either handle a location in the flash memory to a corresponding location in 

desired ISDN connection (e.g., call send or receive) or, e.g., 60 the DRAM to eliminate the discrepancy. O/S 4010 interrupts 

dynamically switch the functionality of a given B -channel to and completely preempts execution of process 1700 wnen- 

handle a voice call (or revert back to a data connection) ever any process, within application software 400, then 

during an on-going ISDN connection. needs to be executed. Execution of process 1700 then 

Within serial EPROM and watchdog timer 380, the Eth- resumes once the CPU is to return to an idle state, 
emet address of the LAN modem itself, and other fixed 65 FIG. 4B depicts an architectural block diagram of soft- 
configuration information such as a serial number of the ware 400 that collectively executes as foreground tasks 
LAN modem, is stored within the EPROM and serially read shown in FIG. 4 A. As indicated in a key shown in FIG. 4B, 
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thick solid lines denote -data paths; thick and thin dashed 
lines denote signaling and configuration information paths, 
respectively; and thin solid lines denote other process inter- 
actions. 

As shown, overall functionality of software 400 can be 
divided into four basic sections: configuration section 405, 
data section 410, call control section 460 and voice section 
480. Voice section 480 is directed to analog (commonly 
referred to as "voice**) telephony connections provided 
through analog telephone device ports 25 (as shown in FIG. 

Generally speaking, configuration section 405, shown in 
FIG. 4B, contains Configuration Manager process 401 and 
Firmware Upgrade process (FU) 402. Process 401 properly 
configures, e.g., initializes, and executes various software 
processes in the LAN modem. FU process 402 strictly limits 
when information can be written into flash memory 376 (see 
FIG. 3), thus substantially minimizing a chance that the 
contents of the flash memory could become corrupted. 

Data section 410, shown in FIG. 4B, controls transmis- 
sion and reception of data packets, i.e., B-channel packets, 
between the LAN, to which workstations 10 (see FIG. 1) are 
connected, and the appropriate ISDN B-channels to which 
the LAN modem is then connected. 

Call control section 460 interacts with a local ISDN 
switch at a telephone central office to establish and terminate 
ISDN calls in order to appropriately route traffic between the 
LAN, via the switch and PSTN, and a remote network, or to 
connect a near-end analog telephone device connected to the 
LAN modem, via the ISDN switch and PSTN, to a called or 
calling far-end device. 

\bice section 480 establishes and terminates analog tele- 
phone voice connections, over an appropriate B-channel(s), 
involving either one (or both) of analog telephone device 
ports 25 provided by the LAN modem. 

LED Driver 490, though not specifically contained within 
any of sections 405, 410, 460 and 480, suitably energizes, 
under program control, LED indicators (see FIG. 3) to 
indicate current status information, respectively. 

In particular, upon power-up of the LAN modem, Con- 
figuration Manager 401, shown in FIG. 4B, is the first 
process to be executed, with it, in turn, spawning all other 
processes and applications, as needed. In that regard, the 
Configuration Manager launches, controls and terminates, as 
needed, the execution of various software processes and 
applications that collectively establish an ISDN connection, 
properly handle B-channel data packet traffic during that 
connection and terminate the ISDN connection at the con- 
clusion of the call. Furthermore, if the LAN modem has not 
yet been initially configured, Configuration Manager 401 
updates certain portions of local database 416 with data 
representing the present configuration of the LAN modem 
and its users. The database collectively stores, e.g.: a serial 
number, product name and software version of the LAN 
modem; an Ethernet address of the LAN modem; an IP 
address and subnet mask of the LAN modem itself; status 
information as to whether DHCP (dynamic host control 
protocol) server 418 and DNS (domain name system) server 
421, shown in FIG. 4B, in the LAN modem are each 
currently enabled or not; a range of private IP addresses 
available for assignment to the workstations that connect to 
the LAN; an indication as a type of ISDN switch to which 
the LAN modem is connected and the SPIDs associated with 
the ISDN directory numbers assigned to the LAN modem; 
various usage parameter valves, such as minimum call 
connect time and inactivity periods; and a profile for each 
workstation connected to the LAN; and a profile for each 
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different network service provider that can be accessed by 
one or more of the workstations through the LAN modem. 
Various portions of this information, such as the serial 
number, product name, and private IP address range are 

5 initially stored in the EPROM (within EPROM and watch- 
dog timer 380 shown in FIG. 3) and after a power-on reset 
has occurred, copied into the flash memory. 

To digress slightly, FIGS. 13A and 13B respectively 
depict host list 1300 and provider list 1350 which are also 

10 both stored within DPAM 372 (see FIG. 3), and used by our 
inventive source-based routing process. 

Host list 1300, as shown in FIG. 13 A, contains stored host 
profiles having an entry for each separate workstation (host) 
that can be connected to the LAN. For each host, its 

15 corresponding entry, of which entry 1310 is typical, specifies 
its machine name, its IP address and its Ethernet address. In 
addition, each host entry contains permission data which 
specifies, for each network service provider (SP) accessible 
through the LAN modem, those providers which that par- 

20 ticular host can access. Initially, during a system power-up 
occurring after a factory default reset, and as shown in FIG. 
13A, for each different host, the name of that host is set to 
indicate an unknown value, e.g., " UnknownPC_l" for host 
1; the IP address for that host is set to a different private IP 

25 address within a specified range, e.g., "IPAddress_l"; the 
Ethernet address for that host is set to zero; and permission 
is granted to that host to access all network service provid- 
ers. Initially the LAN modem assigns itself a private IP 
address of illustratively 192.168.1.1, as a default value, with 

30 each host entry being assigned a different default private IP 
address within the range 192.168.1.2 to 192.168.1.5. Should 
the address of the LAN modem change to place the LAN 
modem on the same subnet as a workstation, then the default 
IP address in each host entry will be automatically changed 

35 accordingly such that the LAN modem and all the hosts are 
always on the same subnet. Though the preferred embodi- 
ment of the LAN modem illustratively accommodates four 
hosts and four network service providers, list 1300 can be 
readily extended, as shown, to accommodate any number of, 

40 e.g., m, hosts and, e.g., n, network service providers (where 
m and n are integers). 

Network service provider list 1350, shown in FIG. 13B, 
contains a separate entry for each network service provider 
for which the LAN modem has been configured to access. 

45 Though the preferred embodiment of the LAN modem 
accommodates four different (user-defined) network service 
providers, hence necessitating four separate entries 1350j, 
1350^ 1350 3 and 1350 4 , in list 1350; this list and hence the 
LAN modem can be readily expanded to afford access to any 

50 number, e.g., n (corresponding to entry 1350„), of different 
pre-defined network service providers. For any such pre- 
defined network service provider, its corresponding entry (of 
which 1350j is typical) specifies: its name; its ISDN direc- 
tory telephone number; a valid user account (USER ID) 

55 thereon; a password for that account; whether that provider 
(ISP) is an Internet service provider or a private network 
(PN) if that service provider is a private network, whether 
the Internet can be accessed through that network; if that 
service provider is a private network, the network identifi- 

60 cation (including, e.g., IP address of the provider and subnet 
mask pairs) and domain name thereof; and other fields not 
relevant hereto. Any host profile can be updated by the 
Configuration Manager in response to user entry of new 
configuration data. 

65 Returning to FIG. 4B, database 416 is directly accessed 
from flash memory 376. This database is queried by various 
processes, as discussed below, to provide status and con- 
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figuration information, as needed, for use in properly connection to a workstation, to FU process 402 for writing 

establishing, maintaining and terminating ISDN suitable replacement code into the flash memory, 

connections, and properly routing packet traffic between a PPP daemon process 440 implements the conventional 

remote network and any of the workstations connected to the and widely known PPP protocol for a given data connection 

LAN or any of the two analog telephone devices connected 5 between a workstation and its remote PPP peer, e.g., a 

to the LAN modem; or among the workstations themselves, network service provider. Specifically and to the extent 

as appropriate. relevant, the PPP protocol is comprised of three major 

To control the integrity of the contents of flash memory components (layers), all of which are advantageous for use! 
376 (see FIG. 3), specifically program code and data stored in an ISDN networked connection: (a) a link control proto- 
therein, FU process 402, shown in FIG. 4B, implements a 10 col (LCP) for establishing, configuring and testing an end- 
key-based lockout to greatly limit those instances, as well as to-end data-link, e.g., ISDN, connection and authentication 
the time intervals thereof, during which the flash memory is protocols for authenticating that connection; (b) a multi-link 
writeable, Le., during which an operating mode of the flash PPP layer for utilizing both B-channels simultaneously; and 
memory is changed from read-only to read/write. Through (c) a network layer which consists of network control 
such a lockout (which is described in detail below in is protocols (NCPs), a compression control protocol (CCP) for 
conjunction with FIG. 16), the contents of the flash memory controlling data compression, and Bandwidth Allocation 
can be changed only when a requesting process presents an Control Protocol (BACP) for controlling addition and 
appropriate key, that matches a corresponding predefined removal of a second multi-link channel. With this in mind, 
key, and a write flash request has been received from, e.g., once an ISDN connection has been connected, the PPP 
a remote file server, to initiate writing new firmware into the 20 daemon negotiates, upon user request, with a remote PPP 
flash memory. Collectively, Firmware Assurance Manager peer as to whether multi-link PPP is to be used or not over 
process 1700 — which is discussed in detail below in con- that connection. In particular, once the LCP protocol has 
junction with FIG. 17 which executes as, e.g., a lowest- been successfully negotiated, daemon process 440 then 
priority background application process, and FU process monitors and authenticates, through suitable authentication 
402 attempt to minimiz e any corruption to and continually 25 protocols (e.g., password authentication protocol and chal- 
maintain the integrity of the firmware executing within the lenge handshake authentication protocol— both of which are 
LAN modem. In addition, key controlled access, though not not specifically shown), the users on both sides of the 
under control of the FU process, is used to limit write access connection; and monitors the IP protocols in use on both 
to the flash memory for profile modifications. sides of the connection. After authentication, then, per user 

Data section 410 contains drivers, local applications, 30 request, daemon process 440 establishes a multi-link PPP 

processes, stored web page components and page templates, connection, if de(sired and supported by the PPP peer, in 

a web server and routing tables. order to utilize both B-channels for data transport during a 

The processes include TCP/IP process 425, PPP daemon common ISDN call, hence creating a single virtual digital 

process 440, secondary router (SR) 450 and Bandwidth channel providing, with use of compression, as much as 256 

Manager (PM) 453. Of these processes, TCP/IP process 425 35 Kbits/sec of available bandwidth; and determines whether, 

implements a basic routing engine in the LAN modem. In through the network layer protocols and specifically through 

that regard, process 425, lying at the heart of data section appropriate negotiation of the compression control protocol 

410, conventionally implements the TCP/IP protocol stack (CCP), whether compression will be performed by the LAN 
and destination-based routing. This process provides all modem. If CCP has been successfully negotiated, then 
processing for IP, TCP (transmission control protocol), UDP 40 Compression/decompression module 438 provides local 
(user datagram protocol) and ARP (address resolution "Stac" compression and decompression of packet data, 
protocol) protocols. This process also provides a standard Furthermore, multi-link PPP involves segmenting, at a trans- 
and conventional "sockets" interface to various local appli- mitting DCE, a message frame into sub-frames and simul- 
cations situated at the top of the stack, such as Telnet server taneously sending sub-frames over both B-channels 

411, HTTP (hypertext transfer protocol) daemon 415, DHCP 45 whereupon, at a PPP peer, those sub-frames are properly 
server 418 and DNS server 421; and a common network re-assembled and re-ordered to reconstitute the single raes- 
interface to all drivers situated at the bottom of the stack. In sage frame. PPP daemon process 440 performs this segmen- 
particular, process 425 accepts incoming IP packets from the tation for outgoing packets, emanating from the LAN 
LAN, as supplied by Ethernet driver 428. In that regard, modem, over each B-channel and re-assembly for incoming 
each of these packets, as conventionally occurs, was so IP packets, to the LAN modem, from each such channel, 
encapsulated, as, payload data, within an Ethernet packet PPP daemon process 440 also interacts with IP Address/ 
and is extracted therefrom by Ethernet driver 428. As such, Port Number Translation module 435 and SR process 450. 
process 425 either routes the IP packet to either one of the The IP Address/Port Number Translation module provides 
local applications or protocols for processing, based on a network address translation (NAT), between private and 
protocol ID and well-known port number contained within 55 public IP address pairs, to permit users at multiple worksta- 
the packet, or, with appropriate IP address and port number lions to simultaneously share a single user account at a 
translation as needed and discussed below, onward to the network service provider, such as an ISP. This process 
appropriate B-channel for carriage over a remote network. ensures that IP packets, based on their transit direction 
Specifically, if the IP address of the packet matches that of through LAN modem 300, i.e., directed to workstations on 
the LAN modem, then the local application to which the 60 the LAN or to the remote network, will contain proper IP 
packet is routed is determined by a protocol ID and port addresses to delineate correct sources and destinations to 
number contained in the packet itself. This routing will be facilitate sharing of a single network, e.g., ISP, account. In 
fully described below in detail in conjunction with Primary this regard, module 435 will translate the private IP source 
Router (PR) process 1100 shown in FIG. U. In addition, addresses of all outgoing packets from the LAN into a single 
during a software upgrade, TCP/IP process 425 routes 65 public IP source address, Le., that associated with the LAN 
incoming packets with replacement code, via an ISDN modem itself (and either statically or dynamically assigned 
networked connection to a remote file server or from a LAN to the LAN modem) and substitute that address for the 
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private IP address within each of these outgoing packets. 
These packets with the substituted public address are then 
provided by daemon process 440 to B-channel driver 442 for 
transport, over an appropriate B-channeI(s), to the network 
service provider. Hence, the LAN modem will effectively 
multiplex all these outgoing packets onto a common net- 
work connection. 

Similarly, incoming IP packets from the common network 
service provider, and provided via driver 442, will possess 
a single common public destination IP address. Module 435 
will translate that single public destination IP address in each 
of these incoming packets into an appropriate private IP 
address of the corresponding workstation to which that 
packet should be destined. For each such incoming packet, 
module 435 substitutes the private IP address for the public 
address in that packet and then provides the resulting packet, 
via PPP daemon process 440, to TCP/IP process 425. Hence, 
the LAN modem effectively de-multiplexes all these incom- 
ing packets to separate network connections on the LAN. 

This translation also encompasses suitably translating the 
port number field in the IP packets (specifically the source 
port number field, if the packet is traveling on the LAN in 
a direction towards the network service provider; or; the 
destination port number field, if the packet is traveling on the 
LAN in a reverse direction, i.e., to a workstation). The port 
number field, in this instance, specifies the particular TCP or 
UDP application session, such as for Telnet, HTTP, FTP, or 
some other application, for which the packet is either 
destined to or from which it is emanating. This translation 
ensures uniqueness of a set of source/destination IP 
addresses, protocol ID and source/destination port numbers 
in packets that flow between unique client/server applica- 
tions and pass through the LAN modem, and hence provides 
unambiguous internal packet routing in the LAN modem 
between all the client hosts (i.e., workstations) connected to 
the LAN modem and associated remote servers connected 
thereto via an ISDN connections,). 

The IP address translation is effectuated through our 
inventive two-level source-based addressing. As discussed 
below in conjunction with FIGS. 10, 11, 12A-12D, this 
addressing relies on using both destination and source IP 
addresses. Destination IP addresses for each host are stored 
within Destination-Based Routing Table (DBRT) 432; while 
B-channel and service provider information are stored 
within Source-Based Routing Table (SBRT) 446. Both of 
these tables are solely maintained in DRAM 372 within 
memory 370 (see FIG. 3). DBRT 432 is used by TCP/IP 
process 425, shown in FIG. 4B, to first determine whether an 
IP packet is destined for a particular workstation (host) on 
the LAN, one of the local applications executing within the 
LAN modem, or a remote destination, such as a remote 
network. Should a packet be destined or incoming from a 
remote network, hence requiring public-private IP address 
translation, IP address/port translation (NAT) module 435, in 
conjunction with addressing information stored with SBRT 
446, provides the public-private address translation 
(including port number translation, if required), when nec- 
essary. NAT module 435 contains suitable public and private 
source and destination IP address information and source 
and destination port number designations for packets then to 
be carried over that channel The specific algorithm which 
implements address translation will be discussed below in 
conjunction with FIGS. 10, 11 and 12A-12D. 

A description of the algorithm used for Network Address 
Translation (NAT), in essence, is provided in K. Egevang 
and P. Francis in "Informational RFC (Request for 
Comment) 1631 " Internet Engineering Task Force (IETF), 
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May 1994, which is incorporated by reference herein: An 
end-to-end connection between a client application running 
on a workstation on the LAN side and a server application 
on the Remote Network (on the WAN side) is identified by 

5 the following parameters: (a) source and destination IP 
addresses; (b) Protocol number (to identify the Transport 
layer protocol, on top of IP, such as TCP or UDP); and (c) 
Source and destination Port numbers (to identify the appli- 
cations on top of TCP or UDP). 

10 As shown in FIG. 2C, all traffic generated towards the 
LAN modem from the Remote Network side will be directed 
to IP address 198.6.1.1. The LAN modem will have to 
demultiplex this traffic and deliver it to the appropriate 
workstation on the LAN. This will always require a trans- 
is lation from IP address 198.6.1.1 to 192.168.1.2-5. In the 
other direction, the LAN modem will have to multiplex the 
traffic from multiple LAN side workstations to the same 
WAN connection. This will always require a translation 
from IP addresses 192, 168.1.2-5 to 198.6.1.1. 

20 A translation may also be required in the LAN side Port 
number field (Source Port number field, if the packet is 
going in the LAN to Remote Network direction; in Desti- 
nation Port number field, if the packet is going towards a 
workstation on the LAN). This translation will be needed to 

25 ensure the uniqueness of the set of Source/Destination IP 
addresses, Protocol number and Source/Destination Port 
numbers, in packets flowing between unique client/server 
applications and passing through the LAN modem. Port 
number translation is effectuated by selecting an available 

30 port number from a range and searching existing entries in 
a NAT table to determine if this selected port number is 
already in use. If the number is free, that number is then used 
as a translated port number. Alternatively, if the selected 
number is in use, a next successive port number is selected, 

35 and so on, to locate a free port number for use in translation. 
As an example, assume that the workstations with IP 
addresses 192.168.1.2 and 192.168.1.4 wish to communi- 
cate with the same server application on the same worksta- 
tion on the Remote Network (having an IP address IP_wl). 

40 Assume that the TCP protocol has to be used (Protocol 
number*=6), and that the server application is Telnet (Port 
number=23) in both cases. If both workstations, 192.168.1.2 
and 192.168.1.4, select the same port number (for example, 
Port number=12) on their side to identify their client 

45 applications, then this port number must be translated by the 
LAN modem (for one of the workstations) to be able to 
unambiguously route packets (since on the WAN side of the 
LAN modem, 192.168.1.2 and 192.168.1.4 will be trans- 
lated to 198.6.1.1). Without port number translation, packets 

50 coming to the LAN modem from the WAN side, with Source 
IP address IP u i, Protocol number 6, Source Port number 
23, Destination IP address 198.6.1.1, and Destination Port 
number 12 will be unroutable (because LAN modem will 
not know whether to send a packet to workstation 

55 192.168.1.2 or 192.168.1.4). 

FIG. 13C depicts the structure of Destination-Based Rout- 
ing Table 432. As shown, this table contains two entries: 
entries 1352 and 1354. These entries specify an outgoing 
network connection to be used, i.e., the Ethernet LAN or an 

60 ISDN connection, for a packet being routed to a given 
destination, other than the LAN modem itself. In that regard, 
TCP/TP process 425 will access this table, for each outgoing 
packet other than those for the LAN modem itself (such as 
for one of local applications 1000), using the destination IP 

65 address of that packet, to locate an entry in the table that 
contains that address. The entry will specify an outgoing 
network interface to be used in routing the packet onward. 



6,023,724 

23 24 

Specifically, for the example shown in the figure, for packets connection — the router generally being unreachable by any 

having a destination IP address of, e.g., 192.168.1.0 and a network device. Inasmuch as the serial port was used just to 

subnet mask of 255.255.255.0, table 432, through entry configure the router, and generally just to enter proper 

1352, specifies that each such packet is to be routed over the network addresses, this port was generally used rather 

LAN. Hence, those packets will be applied by TCP/IP 5 infrequently and oftentimes only once during the service life 

process 425 to Ethernet driver 428 for subsequent routing of the router. Inclusion of such a serial port and proprietary 

over the LAN. Should the IP address of the LAN modem software not only added cost to the router itself but also 

change from its default value, the LAN address will be properly specifying the network addresses was oftentimes 

changed accordingly. Alternatively, for packets that contain rather tedious and time-consuming, thereby burdening its 

any other destination IP address (when the table is accessed 10 installer and further incurring additional cost, 

for such packets, the address will be those other than the IP Advantageously, ISDN router 305 (see FIG. 3) dispenses 

address of the LAN modem itself), then table 432, specifies with the need to use any serial port as well as any proprietary 

through entry 1354, that such packets (with any subnet software in order to configure the LAN modem, 

mask) will be routed over an ISDN connection. Hence, these In accordance with the teachings of the present invention 

packets will be applied by TCP/IP process 425 to PPP 15 and returning to FIG. 4B, software architecture 400 of the 

daemon 440 for subsequent routing over the proper LAN modem also includes web server 412, together with, as 

B-channel to an appropriate network service provider. part of local TCP/IP applications 1000, HTTP process 415 

FIG. 13D depicts the structure of Source-Based Routing and DHCP server 418. Together, these three components 

Table 446. This table is updated by SR process 450 and permit the router to configure itself, through any workstation 

stored within DRAM 372 in memory 370 shown in FIG. 3. 20 connected to the LAN, by interacting with a standard 

As shown in FIG. 13D, this table contains entries 1390, commercially available web browser (such as Netscape 

each of which specifies the status of a current ISDN con- Navigator available from Netscape Corporation or Internet 

nection to a workstation on the LAN. Inasmuch as the Explorer available from Microsoft Corporation) executing 

preferred embodiment of the LAN modem accommodates on that workstation and regardless of whatever the IP 

four workstations, then SBRT 446 need only contain eight 25 address of the workstation happened to be at the time. In 

such entries 1390 with two entries per workstation. In that essence, and as described in considerable detail below in 

regard, entries 1390 1 contains separate entries 1390 1X and conjunction with Initial Configuration procedure 900 shown 

1390 12 for workstation (host) 1, entries 1390 2 contains in FIGS. 9A-9C, whenever the LAN modem is taken "right 

individual entries 1390 21 and 139022 for host 2, and so forth out of the box", connected to a workstation, using static IP 

for the remaining hosts (in the preferred embodiment these 30 addressing, and then energized for the first time, the IP 

hosts are illustrative workstations 10 a , 10^, 10 c and 10 d address of the LAN modem will utilize a default value that, 

shown in FIG. 1). This table can be readily expanded to in all likelihood, will have a subnet value that will not match 

accommodate m different workstations through inclusion of that of the workstation. While such a mis-match would 

additional entries, here being up to entries 1390 m shown in totally frustrate any network communication between a 

FIG. 13D containing entries 1390 ml and 1390^ for host m. 35 conventional router and a workstation connected to it over 

Each entry specifies, through separate fields, the number of an Ethernet connection, the LAN modem surmounts this 

the B-channel in use for that connection (channel B l7 B 2 or deficiency by automatically adapting its current network 

both), whether the PPP or multi-link PPP protocol has been settings in order to establish network communications with 

successfully negotiated and is in use for that connection, and the workstation and illustratively with a web browser 

the network service provider to which the connection is the 40 executing thereat. Specifically, the LAN modem calculates, 

made. Furthermore, to expedite packet routing over estab- given the IP addresses of the workstation and the LAN 

lished connections to any permitted network service modem, a subnet address for the LAN modem that places 

provider, a network II) for each such permitted service both the LAN modem and the workstation on the same 

provider for the corresponding host is cached, in separate subnet. Finally, the LAN modem stores the IP address and 

fields as cached data 1392, within each entry in the SBRT. 45 subnet values for the LAN modem in database 416 and 

For each permitted network service provider, the network ID automatically resets the LAN modem so that these 

includes an IP address of that provider and subnet mask pairs addresses, including the subnet address, over-ride the default 

therefor. values. Thereafter, the workstation and the LAN modem 

As noted above and now returning to FIG. 4B, the LAN communicate through the web browser and the hypertext 

modem also includes web server 412. This server is used to 50 transport protocol. 

initially configure the router and thereafter to indicate net- If the workstation is using dynamic IP addressing, then, in 

work failure messages. The advantages inherent in employ- response to network IP packets broadcast from the 

ing an internal web server will now become clear, though we workstation, specifically DHCP request packets generated 

again divert somewhat from our discussion of FIG. 4B but by the workstation, DHCP server 418 assigns an available IP 

now to broadly discuss this inventive aspect. 55 address to the workstation and then suitably notifies the 

In particular, commercially available routers are typically workstation of this address. The DHCP server obtains the 

configured through an external PC that is connected to the Ethernet address and name of the workstation from the 

router through RS-232 serial ports on both the router and the DHCP Request packet. 

PC. Configuring a router in this fashion not only requires a As such, and in response to a DNS request packet from the 

serial port on the router, and associated internal interface 60 workstation — as discussed in detail below, web server 412 

circuitry, but also a proprietary configuration program that will then dynamically construct a default web page through 

must be executed on the PC in order to properly set, inter which the user can choose to configure the LAN modem, 

alia, network parameters in the router. Such a connection has Should the user then choose to configure the LAN modem, 

been traditionally required for the simple reason that until the web server will generate a predefined sequence of 

such a router was configured with its proper network 65 graphical web pages with user entry fields through which a 

addresses, specifically its IP address and subnet mask, user at the workstation will interactively enter network 

packets could simply not be routed to it over a network parameters and other required data to properly configure the 
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LAN modem. Once all the data has been entered, the LAN * of the fault, Le., the -fault occurs but the user receives no 
modem will have been completely configured. Later, by indication of it on, e.g., his(her) browser. Not only is the user 
appropriately accessing the web server within the LAN annoyed by this type of fault handling, but also the user is 
modem and selecting an appropriate "hotlink" to a top-level forced to wait, owing to a lack of information which leads 
configuration page, the user can then re -configure the LAN 5 to an expectation (which later proves to be unwarranted) that 
modem as desired. While the configuration is generally the fault will resolve itself, which can be rather time- 
accomplished through a web browser executing on the consuming and frustrating. 

workstation, other client based TCP/IP applications, such as Advantageously, the inventive LAN modem also 
telnet, can be used instead to configure the browser. substantially, if rot totally, eliminates these particular den- 
Rather than main taining a file store containing a file for 10 ciencies in the art. 
each separate predefined web page in its entirety, partial- Specifically should such a fault condition arise that affects 
larly those containing graphics, which are then simply a remote network connection, via the ISDN B-chanocl(s), 
accessed — as is the case with conventional web servers and then in use by a workstation on the LAN, web server 412 in 
is costly in terms of memory, web server 412 constructs web the LAN modem, recognizing this condition by reading a 
pages in real-time. These pages are constructed from pre- 15 then current value of a global variable which reflects this 
defined stored templates (flrustratrvely, for the preferred particular fault, constructs and downloads a predefined web 
embodiment, approximately 600 bytes long) containing page to the workstation. This page, when displayed by a 
hypertext markup language (HTML) code that is common to browser thereat, informs the user of the specific nature of 
all pages. For display of any one page, web server 412 that condition such that the user can then take appropriate 
simply accesses the stored code for the template and 20 action, such as, e.g., establishing a remote session to the 
dynamically inserts appropriate predefined code segments network destination at a later time or simply re-transmitting 
therein in lieu of so-called "placeholders)" in the template a message. This inventive aspect is discussed below in detail 
based on a specific event that invoked display of that in conjunction with FIGS. 22-26. Alternatively, the browser 
particular page. These segments can represent dialog boxes, can be executing on a remote host connected over the ISDN 
graphics, predefined textual messages or, generically . 25 connection to the LAN modem. 

speaking, any object, whether HTML or otherwise, that As noted above, data section 410 also includes, as local 

needs to be selectively presented to a user either for display TCP/IP applications, Telnet 411 and DNS server 421. 

and/or to solicit a response, such as an item of data or a Telnet 411, which is conventional in nature, allows a 

selection among a list of predefined data values, from the remote computer, of a wide variety, to communicate, as a 

user. The manner through which code for such a template 30 remote Telnet client, with the LAN modem as a Telnet 

and all its associated objects is generated and the specific server, hence bypassing web server 412. This application is 

manner through which web pages are dynamically con- primarily used for debugging the LAN modem and hence is 

structed therefrom are discussed in detail below in conjunc- likely to see little use in actual installations. Though, through 

don with File Creation process 2800 shown in FIG. 28 and this application, the LAN modem can be remotely config- 

illustrative code shown in FIGS. 30A-30B and 31. Since 35 ured via a networked connection, either via the LAN itself 

few full web pages are stored, memory requirements become or through an ISDN networked connection, should a need 

rather modest. Collectively, the templates and all page arise to do so. 

components are stored within database 416 in flash memory Furthermore, in accordance with the present inventive 

376 (see FIG. 3) and, in the preferred embodiment of the teachings, DNS server 421 provides local name-to-address 

LAN modem, consume only approximately 200 Kbytes of 40 resolution such that, for user convenience, each workstation 

storage space. Once a page is constructed by web server 412 on the LAN can be addressed in terms of its machine name 

(see FIG. 4B), a file for that page is then provided by the web rather than its IP address. Moreover and advantageously, 

server to HTTP process 415 which suitably packetizes and DNS server 421, in conjunction with DHCP server 418, 

encapsulates that file, using the hypertext transfer protocol operates transparently of any user to acquire machine names 

(HTTP). The resulting file is provided by HTTP process 415 45 of all the workstations connected to the LAN and then 

to TCP/IP process 425 for eventual routing, over the LAN, provide suitable machine name to IP address resolution, as 

to the associated workstation. User responses, in HTTP needed, for all communication between the LAN modem 

form, from the workstation to each web page are routed by and these workstations as well as between any pair of 

TCP/IP process 425 to HTTP process 415 for suitable workstations themselves. These inventive aspects are dis- 

interpretation, such as constructing and transmitting a next 50 cussed below in detail in conjunction with DHCP Induced IP 

successive page to the user or storage of user-supplied Address FRequest procedure 1400 and DNS Induced IP 

configuration data. Web server 412 stores such user-supplied Address Request procedure 1500 shown in FIGS. 14 and 

configuration data within database 416 for subsequent 15A-15D, respectively. 

access and use. The architecture of web server 412 is For multi-link connections, Bandwidth (BW) Manager 

discussed in considerable detail below in conjunction with 55 (BM) process 453, shown in FIG. 4B, monitors the number 

FIGS. 18-21, with specific examples of dynamic web page of B-channels allocated to a given ISDN connection for a 

generation being discussed below in conjunction with FIGS. data call and, if both channels have been allocated to handle 

22-27. a given ISDN data call, deallocates one of those channels, on 

Moreover, in the event of a network fault or other con- request and where possible based on under-utilization of that 

dition that affects a connection to a remote network and/or 60 channel, to simultaneously establish another ISDN call to a 

server thereon, conventional routers do not indicate the different destination. This new ISDN call can either be a data 

specific nature of that fault to any local client connected to call to another remote network destination or an analog 

the router. This, in turn, relegates the user at that client to voice call to a far-end analog telephone device. This 

rely on an error message, in those instances when it is dynamic channel assignment can also automatically occur 

provided by the network, that is often rather cryptic at best 65 whenever, e.g., a user lifts a handset (i.e., goes "off-hook") 

and more often simply not provided at all. In the latter of an analog telephone connected to the LAN modem, 

situation, the user simply waits in basically total ignorance through either of the analog telephone device ports, during 



* II • 



6,023,724 



27 



28 



an on-going ISDN call, thereby causing a "call request" or 
a "call connect" message to be generated by AU process 481 
and hence an appropriate message to be produced by Call 
Control process 461. 

In particular, assume that both B-channels are allocated, 
as would occur through prior successful negotiation of 
multi-link PPP, to carry a current ISDN data call to a giver 
network service provider. Should TCP/IP process 425 need 
to route a packet to, e.g., a different network service 
provider, an ISDN connection will first need to be estab- 
lished for this new provider. Hence, Call Control (CC) 
process 461 will send a request to SR process 450 to 
ascertain whether the new call can be accommodated. SR 
process 450 then passes a request to BM process 453. If, 
based on a response from the BM process, one of these 
channels can be de-allocated, SR process 450 will inform 
PPP daemon process 440 which, in turn, will issue a suitable 
PPP control message, specifically a Bandwidth Allocation 
Protocol (BAP) message, to its PPP peer to revert to use of 
a single B-channel for the current ISDN call. BM process 
453 will deallocate the channel from the existing data call. 
CC process 461 will then initiate an ISDN call over the now 
available B-channel. Once a link is established thereover 
BM process 453 will update its data. Thereafter, whenever 
the new call is concluded, CC process 461 will suitably 
inform SR process 450, which will inform BM process 453 
accordingly. As a result, the recently allocated B-channel is 
now available to be re-allocated, where possible, to a 
different ISDN call, should the need exist. If a multi-link 
PPP data connection has been successfully negotiated and is 
currently in progress over the other B-channel, then daemon 
process 440 can request use of this now available B-channel 
for this connection. If BM process 453 decides that a 
sufficient need exists to utilize the now available second 
B-channel for this data connection, the BM will so indicate 
this to SR process 450. SR process 450, in turn, will suitably 
inform BAP within PPP daemon process 440 to establish a 
connection through the second B-channel. Through nego- 
tiations with BAP in the PPP peer, if successful, BAP within 
SR process 450 suitably informs the SR process and Control 
process 461 to issue appropriate signaling messages to 
establish an ISDN call over the available B -channel to the 
destination of the current data connection. 

The drivers used within data section 410 include Ethernet 
driver 428 and B-channel driver 442. The Ethernet driver, 
given network packets received from TCP/IP process 425 
and destined to any of the workstations connected to the 
LAN, properly assembles, by encapsulating these packets as 
payload data within Ethernet packets, and transmits the 
resulting encapsulated packets, via the Ethernet hub and the 
Ethernet LAN, to that workstation. Driver 428 also receives 
encapsulated packets from the LAN and destined either for 
the LAN modem itself or a remote network. In this case, 
driver 428 extracts the IP packet from the encapsulated 
packet and applies the former to TCP/IP process 425 for 
subsequent handling. For all such encapsulated packets, 
driver 428 checks the Ethernet addresses of each packet for 
accuracy and performs a cyclic redundancy check (CRC) on 
the entire encapsulated packet for error detection. This 
driver ignores any non-IP packet that might appear on the 
LAN. Driver 442 accepts incoming IP packets appearing on 
the ISDN connection that are destined for the LAN modem 
and routes those packets to PPP daemon process 440 for 
subsequent processing. All outgoing packets provided by the 
PPP daemon process are applied to driver 442 which, in turn, 
buffers each of these packets as needed, and subsequently 
transmits each such packets over the appropriate B-channel 
onward to the remote network for transport to its eventual 
destination. 



Call Control section 460 contains as its high-level soft- 
ware components: Call Control (CC) process 461, 0.931 
process 463, Q.921 process 465 and D -channel driver 470. 
Call Control process 461 manages system resources 

5 within the LAN modem both from the standpoint of locating 
available hardware resources and software drivers and allo- 
cating those resources and drivers accordingly to establish 
analog and digital calls as requested. Call Control process 
461 receives outgoing call requests from either AU process 

lQ 481, as discussed below, or secondary router (SR) process 
450. Upon receipt of such a request from, e.g., SR process 
450 (or from AU process 481), process 461 being event 
driven, will send a "call request" message to and invoke 
Q.931 process 463. Process 463, which is implemented as a 
finite state machine, provides appropriate ISDN Q.931 mes- 

15 sage encoding and decoding for communicating with an 
ISDN switch to control call setup and tear-down. This 
process, along with Q.921 process 465, implements, in 
software, well-known layers 3 and 2, respectively, of ISDN 
call processing. In addition, Q.931 process 463 also 

20 includes: (a) automatic switch detection functionality to 
automatically detect a type of ISDN switch to which the 
LAN modem is connected and appropriately configure the 
router accordingly; and also (b) an automatic SPED (service 
profile identifier) Wizard process to properly configure the 

25 SPIDs for each directory telephone number for the ISDN 
line connected to the LAN modem. Inasmuch as details of 
the automatic switch detection and SPID Wizard process are 
not necessary for a full understanding of the present 
invention, then, for further details on these two aspects, the 

30 reader is referred to co-pending United States patent appli- 
cations entitled "APPARATUS FOR AN IMPROVED ISDN 
TERMINAL ADAPTER HAVING AUTOMATIC ISDN 
SWITCH DETECTION AND METHODS FOR USE 
THEREIN" Ser. No. 08/852,659, and "APPARATUS FOR 

35 AN IMPROVED ISDN TERMINAL ADAPTER HAVING 
AUTOMATIC SPID CONFIGURATION AND METHODS 
FOR USE THEREIN*' Ser No. 08/852,656, both of which 
were filed on May 7, 1997, commonly assigned to the 
present assignee hereof and are incorporated by reference 

40 herein. 

In any event, to establish an outgoing ISDN data (or 
B -channel voice) connection, Call Control process 461 first 
assigns an available B-channel to that call. Thereafter, Q.931 
process 463 issues, over the D -channel, a "call setup" 

45 message. This D-channel signaling message, as well as all 
other such outgoing D-channel messages generated by 
Q.931 process 463, is applied, in turn, to Q.921 process 465 
for proper encapsulation in a Q.921 information frame and 
subsequent transport over the ID-channel, via D-channel 

50 driver 470 and ISDN interface 310 (see FIG. 3), to the 
far-end. Once the ISDN connection is fully established, an 
ISDN "call connect" message is delivered by the local ISDN 
switch, over the D-channel, to the LAN modem, specifically 
via D-Channel driver 470, shown in FIG. 4B, to Q.931 

55 process 463 executing therein. For an incoming ISDN call, 
all incoming D-channel signaling messages received from 
the ISDN line for that call are applied through ISDN 
interface 310 (see FIG. 3) and D-channel driver 470 to 
Q.921 and Q.931 processes 465 and 463 (shown in FIG. 4B), 

60 in seriatim, for appropriate local processing and eventually 
to Call Control process 461 to control the progress of that 
call and allocate (or deallocate) appropriate resources for 
that call, e.g., allocate an available B-channel HDLC driver 
or analog line interface (for a B-channel voice call) or 

65 deallocate it if the call is terminated. D-channel driver 470, 
together with ISDN interface 310, collectively implements, 
in hardware, ISDN layer 1 functionality. 
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TEI Manacer 475, in conjunction with Q.^2t process 465;- 
requests, during call establishment, a so-called "Terminal 
Endpoint Identifier** (TEI) from the ISDN switch to which 
the LAN modem is connected. The TEI is a unique (and 
conventional) identifier used by the LAN modem, and more 
generally any DTE connected to an ISDN switch, to 
uniquely identify itself to the switch. The value of this 
parameter is supplied by the switch to the LAN modem 
during initial communication between the switch and the 
LAN modem arid is thereafter used by the LAN modem in 
each communication with the switch. Inasmuch as the LAN 
modem merely reflects the TEI value supplied to it by the 
switch in each communication to the switch, the actual value 
of the TEI, as assigned by the switch, is immaterial to the 
LAN modem. Should Configuration Manager 401 need to 
tear down and re-establish the ISDN connection to the 
switch, configuration manager 401 will first instruct TEI 
manager 475 to re-initialize the TEI to effectively inform the 
switch that the terminal adapter is no longer connected to it, 
and thereafter instruct the TEI manager to request a new TEI 
value from the switch for subsequent use. 

For a data call, once an ISDN connection is established 
between the LAN modem and a network service provider, 
then digital packet data is routed, on a bi-directional basis 
through Ethernet driver 428, TCP/IP process 425, PPP 
daemon process 440 and B-channel driver 442 to a corre- 
sponding B-channel connected to a remote network accessed 
through that provider. 

\bice section 480 contains analog drivers 482, specifi- 
cally drivers 482 1 and 482^ which operate analog telephone 
interfaces 1 and 2, respectively. Both of the drivers are 
themselves controlled by Analog Unit (AU) process 481. 
The AU process, given a request for an analog connection, 
either for transmitting or receiving an analog (voice) call, 
assigns and binds an available one of the analog drivers to 
the particular analog line interface through which the par- 
ticular analog device is either calling or being called. AU 
process 481 responds to incoming dialed DTMF digits from 
that device as well as switch-hook status (Le., off-hook or 
on-hook), both being detected by the associated analog line 
interface to which that device is connected via analog 
telephone device ports 25, and, for an incoming analog call 
to the device, generates, in response to a suitable D -channel 
control message, a suitable signal to the interface to apply a 
ringing signal to that device. AU process 481 effectively 
establishes an internal connection between a B-channel and 
an analog line interface, and its associated analog device 
port, and controls communication therebetween for the 
duration of the associated analog call through the LAN 
modem. 

In particular, when a user at the LAN modem causes an 
analog device connected to the adapter, such as an analog 
telephone to go "off-hook", i.e., to initiate a call, AU process 
481 sends a "call request" message to Call Control process 
461, as described above, to obtain resources needed to 
complete an analog connection for that device. Whenever 
AU process 481 receives digits from an analog line interface 
and particularly a DTMF receiver therein, such as DTMF 
receiver 354 (see FIG. 3), AU process 481 issues a "send 
digits" message, containing those digits, to the call control 
process. Furthermore, whenever AU process 481, shown in 
FIG. 4B, receives an incoming call request from Call 
Control process 461, such as for a connection via an analog 
interface, such as interface 3501, AU process 481 controls 
the ringer in a local analog telephone device connected to 
that interface. 
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3. Inter-process interactions 

With the above overview and hardware and software 
descriptions in mind, FIGS. 5-8 collectively and diagram- 
matically depict interactions between various higb4evel 
software processes for implementing different call handling 
operations that are performed by the LAN modem. Each of 
these operations and the attendant process interaction will 
now be discussed in turn. To facilitate understanding during 
the ensuing discussions, the reader should simultaneously 
refer to both FIG. 4B and the specific figure for the operation 
then being discussed. 

a. ISDN call setup due to traffic on LAN 

FIG. 5 depicts predominant interactions, in terms of 
inter-process communications, that occur for setting up an 
ISDN call based on traffic on the LAN. 

Let us begin by assuming that a user stationed at a 
workstation on the LAN has just initiated execution of 
his(her) web browser. As such, the browser will attempt to 
access its default web page. In doing so, the web browser 
will generate an HTTP request, in the form of an appropriate 
IP packet, to fetch the page. To simplify matters, it is 
assumed for this discussion, that the HTTP request contains 
the correct IP address of the desired page to be fetched; 
hence requiring no remote DNS translation from a uniform 
resource locator (URL) to that IP address. 

The workstation will place this IP packet, as symbolized 
by line 505, onto the LAN from where it will be received by 
the LAN modem. At this point, the packet needs to be routed 
to a default gateway established for that user. However, no 
ISDN connection yet exists between the LAN modem and 
an appropriate network service provider, e.g., ISP, to handle 
that packet. 

Within the LAN modem, the incoming IP packet will be 
sent, as symbolized by line 510, via Ethernet driver 428 to 
TCP/IP process 425. Process 425 will access Destination- 
Based Routing Table (DBRT) 432 to determine whether, 
from the destination IP address of the packet, that packet is 
destined for any one of local applications 1000 on the LAN 
modem itself or a remote destination. Inasmuch as this 
packet is not destined for either any of local applications 
1000 executing on the LAN modem, TCP/IP process 425 
sends, as symbolized by line 515, the packet to PPP daemon 
process 440 to properly handle the packet. Daemon process 
440 checks the profile for the workstation, stored within 
database 416, to determine the proper peer destination, e.g., 
an ISP or a remote network, for that packet Illustratively, 
four network service provider profiles can be stored within 
database 416. Specifically, process 440, based on the source 
and destination IP addresses of the packet, will determine 
which particular network service provider should carry that 
packet. In addition, the PPP daemon process through SR 
process 450, wherein the latter interrogates Source-Based 
Routing Table (SBRT) 446, also determines whether an 
ISDN call is currently established to that particular service 
provider. At this point, it will be assumed that such a call is 
not established. In this case, the packet is placed into a 
waiting queue pending the establishment of an ISDN con- 
nection. PPP daemon process 440 then issues a Call Setup 
Request message, as symbolized by line 520, to SR process 
450 to establish an ISDN call to the particular service 
provider that is to carry the now queued packet. 

Secondary Router (SR) process 450, in response to the 
Call Setup Request message, accesses database 416, spe- 
cifically Network Service Provider list 1350 (see FIG. 13B), 
to obtain the ISDN directory number of the desired network 
service provider to handle this packet. The Call Setup 
Request message, along with the directory ISDN telephone 
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number is then passed, as symbolized by line 525 as shown" 
in FIG. 5, to Call Control process 461. Call Control process 
461, interacting with Q.931 and Q.921 processes 463 and 
465, respectively, will establish an ISDN call over an 
available B-channel to this network service provider. 

Once an ISDN call has been properly established to the 
desired network service provider, Call Control process 461, 
in response to appropriate call completion messages sent to 
it by Q.931 process 463, will issue, as symbolized by line 
530, a Connect Acknowledgement (ACK) Indication mes- 
sage to the secondary router process. The secondary router 
process, in turn, will issue a Link Establishment Request 
message containing the user account and password for the 
network service provider (to establish a session with that 
provider), as symbolized by line 535, to instruct the PPP 
daemon process to establish a network link and negotiate 
compression (or not) and multi-link PPP (or not) as specified 
in configuration data stored in database 416. As such, PPP 
daemon process 440 will undertake to negotiate, across the 
ISDN connection to its peer, all PPP protocols (including 
network control protocols such as CCP, and multi-link PPP 
as specified in the database). In addition, the two PPP peers 
will also negotiate whether an IP address of the router will 
be dynamically assigned by the network service provider, 
through a DHCP server thereat, or not (i.e., use of a static 
public address). Once all the PPP negotiations are success- 
fully concluded, PPP daemon process 440 will suitably 
update an entry in SBRT 446 to indicate the B-channel(s) in 
use for this call and the options being used therefor (e.g., 
multi-link PPP). In addition, PPP daemon process 440 will 
suitably inform the secondary router, by issuance of a Link 
Establishment Indication message and as symbolized by line 
540, of the successful PPP negotiation. The secondary 
router, in turn, will inform Bandwidth Manager process 453 
accordingly as to the bandwidth of the connection then 
established and the B-channel(s) therefor. 

Now with the data connection having been completely 
and properly established to the desired network service 
provider, the secondary router will issue a Call Connect 
Indication message, as symbolized by line 545, back to PPP 
daemon process 440. In response, the PPP daemon process 
will again check SBRT 446 to verify the B-channel(s) in use 
for this call. Once verified, the PPP daemon will remove the 
packet waiting for transfer from the waiting queue and will 
send that packet to B-channel driver 442 for transport to the 
network service provider over the B-channel(s) now estab- 
lished for the call. Secondary router 450 will also issue, as 
symbolized by line 550, a Call Connect Indication packet to 
DNS server 421 which instructs the DNS server to save the 
remote destination ID, including, e.g., IP address of the 
network service provider and subnet mask pairs, and 
B-channel(s) number for this workstation. 

Any subsequent packets to be carried during this session 
between this network service provider and this workstation 
will simply be routed to the provider via the LAN, Ethernet 
driver 428, TCP/IP process 425, PPP daemon process 440, 
B-channel driver 442, and the appropriate B-channel(s), as 
specified by the SBRT 446, connected to this provider. 

b. ISDN call setup due to DNS request 

FIG. 6 depicts interactions, in terms of predominant 
inter-process communications, that occur within the LAN 
modem for setting up an ISDN call based on a DNS (domain 
name system) request. This interaction is somewhat similar 
to that shown in FIG. 5; however, here a workstation on the 
LAN is requesting translation of a URL into a corresponding 
IP address rather than supplying the correct IP address. Here, 
the assumption is made that an ISDN call has not been 
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- established to a network service provider when the work- 
station issues its DNS request. 

Let us begin by assuming that a user stationed at a 
workstation on the LAN has just initiated execution of 

5 his(her) web browser. As such, the browser will attempt to 
access its default web page. In doing so, the web browser 
will generate an HTTP request, in the form of an appropriate 
IP packet, to fetch the page. Here, however, the browser only 
has a URL for this page and not its IP address; hence, 

10 requiring DNS translation of that URL into a corresponding 
IP address. Assume that the DNS server residing in the LAN 
modem is already configured to be the DNS server for the 
workstation, hence a DNS query will be sent to the DNS 
server of the LAN modem by the workstation. 

15 The workstation will place this IP packet, as symbolized 
by line 605, onto the LAN from where it will be received by 
the LAN modem. At this point, the packet needs to be routed 
to a DNS server for that user. However, no ISDN connection 
yet exists between the LAN modem and an appropriate 

20 network service provider, e.g., ISP, to handle that packet 
Within the LAN modem, the incoming IP packet will be 
sent, as symbolized by line 610, via Ethernet driver 428 to 
TCP/IP process 425. Process 425 will access Destination- 
Based Routing Table (DBRT) 432 to determine whether, 

25 from the destination IP address of the packet, that packet is 
destined for any local application on the LAN modem itself 
or a remote destination. Inasmuch as this packet is destined 
for DNS server 421, TCP/IP process 425 sends, as symbol- 
ized by line 615, the packet to DNS server 421. This DNS 

30 server will check the stored profiles for the network service 
provider, given the source IP address of this packet, whether 
it can perform the URL translation itself or whether that 
packet needs to be diverted given its source and destination 
addresses, to a particular network service provider. Assum- 

35 ing DNS server 421 can not translate the URL, then the 
packet will need to be routed, over an ISDN connection to 
that network service provider, to a remote DNS server for 
translation. Consequently, DNS server 421 interacts, 
through the secondary router, with SBRT 446, to determine 

40 whether an ISDN connection currently exists to that pro- 
vider. If no such connection is currently established, the 
packet is placed in the waiting queue pending the establish- 
ment of an ISDN connection. A timer is also started to ensure 
that a response can be sent to the workstation if the ISDN 

45 connection fails to be established to the chosen network 
service provider within a predefined period of time, such as 
30 seconds. DNS server 421 then issues a Call Setup 
Request message, as symbolized by line 620, to SR process 
450 to establish an ISDN call to the particular service 

50 provider that is to carry the now queued packet. 

Secondary Router (SR) process 450, in response to the 
Call Setup request message, accesses database 416, specifi- 
cally Network Service Provider list 1350 (see FIG. 13B), to 
obtain the ISDN directory number of the desired network 

55 service provider to handle this packet. The Call Setup 
Request message, along with the directory ISDN telephone 
number, is then passed, as symbolized by fine 625 shown in 
FIG. 6, to Call Control process 461. Call Control process 
461, interacting with Q.931 and Q.921 processes 463 and 

60 465, respectively, will establish an ISDN call over an 
available B-channel to this network service provider. 

Once an ISDN call has been properly established to the 
desired network service provider, Call Control process 461, 
in response to appropriate call completion messages sent to 

65 it by Q.931 process 463, will issue, as symbolized by line 
630, a Connect Acknowledgement (ACK) Indication mes- 
sage to the secondary router process. The secondary router 
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process, in turn, will issue a Link Establishment Request 
message containing the user account and password for the 
network service provider (to establish a session with that 
provider), as symbolized by line 635, to instruct the PPP 
daemon process to establish a network link and negotiate 5 
compression (or not) and multi-link PPP (or not) as specified 
in configuration data stored in database 416. As such, PPP 
daemon 440 will undertake to negotiate, across the ISDN 
connection to its peer, all PPP protocols (including network 
control protocols such as CCP, and multi-link PPP as sped- 10 
fied in the database). In addition, the two PPP peers will also 
negotiate whether an IP address of the router will be 
dynamically assigned by the network service provider, 
through a DHCP server thereat, or not (i.e., use of a static 
public address). Once all the PPP negotiations are success- is 
fully concluded, PPP daemon process 440 will suitably 
update an entry in SBRT 446 to indicate the B-channel(s) in 
use for this call and the options being used therefor (e.g., 
multi-link PPP). In addition, PPP daemon process 440 will 
suitably inform the secondary router, by issuance of a Link 20 
Establishment Indication message and as symbolized by line 
640, of the successful PPP negotiation. The secondary 
router, in turn, will inform Bandwidth Manager process 453 
accordingly as to the bandwidth of the connection then 
established and the B-channel(s) therefor. 25 

Now with the data connection having been completely 
and properly established to the desired network service 
provider, the secondary router will issue a Call Connect 
Indication message, as symbolized by line 645, back to PPP 
daemon process 440. Secondary router 450 will also issue, 30 
as symbolized by line 650, a Call Connect Indication mes- 
sage to DNS server 421. This message instructs the DNS 
server to save the remote destination ID, including, e.g., LP 
address and subnet mask pairs of the network service 
provider, and B-channel(s) number for this workstation, and 35 
to remove the packet from the waiting queue and send that 
packet back to the TCP/IP process 425. The destination IP 
address of the packet will be changed to the IP address of the 
DNS server for the remote network service provider. Once 
this packet is sent, as symbolized by line 655, to TCP/IP 40 
process 425, the TCP/IP process will route, as symbolized 
by line 660, that packet to PPP Daemon process 440. Id 
response, the PPP daemon process will again check SBRT 
446 to verify the B-channel(s) in use for this call. Once 
verified, the PPP daemon process will send the packet, via 45 
B -channel driver 442 and over the B-channel(s) now estab- 
lished for the call, to the particular network service provider 
for DNS translation. 

Any subsequent packets to be carried during this session 
between this network service provider and this workstation 50 
will simply be routed to the provider via the LAN, Ethernet 
driver 428, TCP/IP process 425, PPP daemon process 440, 
B-channel driver 442, and the appropriate B-cbannel(s), as 
specified by the SBRT 446, connected to this provider. 

c. Incoming ISDN call 55 

FIG. 7 depicts interactions, in terms of predominant 
inter-process communications, that occur in the LAN 
modem to process an incoming ISDN call from a remote 
site. This operation would generally occur only in those 
situations where the LAN modem is to be configured from 60 
a remote site. 

An incoming ISDN call will be signified by a Call Setup 
packet being received, as symbolized by line 705, via 
D-cbannel driver 470, from the PSTN. In response to this 
packet, Call Control process 461 will issue, as symbolized 65 
by line 710, a Call Indication message to Secondary Router 
450 to establish a connection over the B-channel specified in 
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the Call Setup packet. In response, the Secondary Router 
will issue, as symbolized by line 715, a Connect Request 
Message to complete an ISDN connection over that 
B-channel through the LAN modem for the incoming call. 

In response to the Connect Request message, Call Control 
process 461, interacting with Q.931 and Q.921 processes 
463 and 465, respectively, will complete an ISDN connec- 
tion through the LAN modem over this B-channel, via the 
PSTN, to a present caller. Once the ISDN connection has 
been completed, Call Control process 461, in response to 
appropriate completion messages sent to it by Q.931 process 
463, will issue, as symbolized by line 720, a Connect 
Acknowledgement (ACK) Indication message to the sec- 
ondary router. The secondary router, in turn, will issue a 
Link Establishment Request message, as symbolized by line 
725, to instruct the PPP daemon process to establish a 
network link and negotiate compression (or not) and multi- 
link PPP (or not) with its far-end PPP peer. As such, PPP 
daemon 440 will undertake to negotiate, across the ISDN 
connection to its peer, all PPP protocols (including network 
control protocols such as CCP. Once all the PPP negotiations 
are successfully concluded, PPP daemon process 440 will 
suitably update an entry in SBRT 446 to indicate the 
B-channel(s) in use for this call and the options being used 
therefor (e.g., multi-link PPP). In addition, PPP daemon 
process 440 will suitably inform the secondary router, by 
issuance of a Link Establishment Indication message and as 
symbolized by line 730, of the successful PPP negotiation. 
The secondary router, in turn, will inform Bandwidth Man- 
ager process 453 accordingly as to the bandwidth of the 
connection then established and the B-channcl(s) therefor. 

Now with the data connection having been completely 
and properly established to the caller, the secondary router 
will issue a Call Connect Indication message, as symbolized 
by line 735, back to PPP daemon process 440. Secondary 
router 450 will also issue, as symbolized by line 740, a Call 
Connect Indication message to DNS server 421 which 
instructs the DNS server to save the remote destination ID 
and B-channel(s) number in use for this call. 

Any subsequent packets to be carried between the LAN 
modem and the caller will be routed through B-channel 
driver 44.2 (and the B-channel(s) for this call), PPP daemon 
process 440 and TCP/IP process 425 (and any local appli- 
cations 1000 accessible therethrough). 

d. ISDN call disconnect due to idle timeout 

FIG. 8 depicts interactions, in terms of predominant 
inter-process communications, that occur within the LAN 
modem for disconnecting an existing ISDN call as a result 
of an idle timeout condition. This operation arises where an 
excessive period of inactivity occurs on an existing ISDN 
connection. To determine an appropriate level of ISDN call 
inactivity, two time periods are predefined in software: a 
minimum call duration of 2 minutes and an idle time interval 
of 30 seconds. These timers are implemented within Band- 
width Manager process 453. The LAN modem will maintain 
an ISDN call active for an illustrative minimum interval of 
two minutes; however, after this period expires, the call will 
be released and the connection torn-down for any period of 
inactivity, here referred to as "idle time", that exceeds 
illustratively 30 seconds. These time intervals, which are 
stored within database 416, are not critical and can be 
appropriately varied during configuration of the LAN 
modem. 

Should an excessive period of inactivity occur, then an 
idle timeout timer, implemented within the Bandwidth Man- 
ager process, will reach the end of its timing interval and 
produce an appropriate indication, such as, e.g., a timer 
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interrupt In response to the expiration of this tuning 
interval, an Idle Timeout message, symbolized by line 805, 
will be generated by the Bandwidth Manager process and 
supplied to Secondary Router process 450. This message 
will also contain the B-channel(s) that is affected and should 
be taken down. With the channels) identified and as sym- 
bolized by line 810, the secondary router will generate a 
Link Termination Request message to PPP daemon process 
440 to terminate the ISDN connection on the affected 
B-channel(s). The PPP daemon process will then send 
appropriate network control packets to terminate the con- 
nection on the affected B-channel(s). PPP daemon process 
440 will also inform its far-end peer that the link is being 
taken down. Once these packets have been sent, PPP dae- 
mon process 440 will update (specifically "cleanup**) SBRT 
446 to reflect that the now current availability of the affected 
B-channel(s). Once the SBRT has been appropriately 
updated, PPP daemon process 440 will issue, as symbolized 
by line 815, a Link Termination Indication message to 
Secondary Router 450 signifying that the ISDN data 
connection, from the standpoint of the PPP protocols, has, in 
fact, been terminated. The secondary router, in turn and as 
symbolized by line 820, will issue a Disconnect Request 
message, to Call Control process 461. This process, in 
conjunction with Q.931 and Q.921 processes 463 and 465, 
respectively, will issue appropriate ISDN signaling mes- 
sages to the PSTN to disconnect, i.e., physically terminate, 
whatever ISDN connection may exist on the affected 
B-channel(s). Once this occurs, Call Control 461 issues, as 
symbolized by line 825, a Release Indication message to 
Secondary Router 450. The secondary router, in turn, issues, 
as symbolized by lines 830 and 835, Call Disconnect Indi- 
cation messages to PPP daemon process 440 and BM 
process 453 and DNS server 421, respectively. In response 
to these disconnect messages, these processes remove any 
entries previously associated with the now terminated ISDN 
data connection. 

4. Flowchart depictions 

Having now described the inter-process interactions for 
various operations performed by the LAN modem, we will 
now turn to describing, through the use of flowcharts, the 
processing, undertaken by CPU 330 (see FIG. 3) within 
ISDN router 305 in the LAN modem, that specifically 
implements various inventive aspects of the LAN modem. 
As will become readily apparent from the following discus- 
sion and the accompanying flowcharts, for several of these 
aspects, the processing utilizes and extends across several of 
the software processes contained within software 400 
(shown in FIG. 4B). To facilitate understanding, the reader 
should simultaneously refer to FIG. 4B throughout the 
following description. 

a. Initial Configuration procedure 

FIGS. 9A-9C collectively depict a flowchart of Initial 
Configuration procedure 900 performed by CPU 330; the 
correct alignment of the drawing sheets for these figures is 
shown in FIG. 9. As noted above, process 900 automatically 
adapts the current network settings of the LAN modem in 
order to establish network communications with the 
workstation, such as through illustratively a web browser 
executing thereat Through this communication, a user sta- 
tioned at the workstation can easily configure the LAN 
modem through the browser. This inventive aspect advan- 
tageously eliminates any need for a serial connection 
between the workstation and the LAN modem for purposes 
of configuring the latter. This procedure primarily utilizes 
processes 412, 415, 418, 425 and 428, and database 416, all 
shown in FIG. 4B. 
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In -particular, upon entry into procedure 900 shown in 
FIGS. 9A-9C, execution proceeds to block 905. This block, 
when executed, determines whether the LAN modem is in a 
factory default state, i.e., whether the LAN modem has 

5 changed its IP address from a factory default setting through, 
e.g., an immediately prior execution of procedure 900. If the 
LAN modem is not in its factory default state, then execu- 
tion exits from procedure 900 via NO path 909 emanating 
from decision block 905. Alternatively, if the LAN modem 

10 is in its factory default state, then decision block 905 routes 
execution, via YES path 907, to decision block 910. 

Decision block 910, when executed, determines if a 
packet has beer, received over the LAN. This packet, if it 
exists, should originate from, illustratively the web browser 

15 executing on the single workstation which is then connected 
to the LAN. If no such packet has yet been received, 
execution loops back to the beginning of this block, via NO 
path 912 and path 973, to await receipt of this packet. 
Alternatively, if a packet has indeed been received over the 

20 LAN, decision block 910 routes execution, via YES path 
914, to decision block 915. This latter block tests whether 
the packet is a unicast or broadcast type packet If the packet 
is from a web browser executing in a workstation using 
dynamic addressing, as intended, then at this point in its 

25 initial handling of the TCP/IP protocol, the workstation is 
expected to broadcast a packet onto the LAN to provoke a 
response, from some other entity then connected to the 
network, that identifies a DHCP server. If the packet is a 
unicast packet, then the packet is simply ignored as being 

30 irrelevant to the configuration process. In this case, execu- 
tion loops back from decision block 915, via paths 916 and 
973, to block 910 pending receipt of the next packet on the 
LAN. Alternatively, if the received packet is a broadcast 
packet, as expected, then decision block 915 routes 

35 execution, via path 918, to decision block 920. This latter 
decision block routes execution, via one of three paths, 
depending upon a specific type of this broadcast packet In 
particular, if the broadcast packet is other than a DHCP 
packet or an ARP (address resolution protocol) Request 

40 packet, then decision block 920 routes execution, via paths 
922 and 924, to block 930 to discard this broadcast packet 
Once this packet has been so discarded, then execution loops 
back, via paths 932 and 973, to decision block 910 to await 
receipt of the next packet. 

45 Alternatively, if the broadcast packet is a DHCP packet, 
then decision block 920 routes execution, via paths 922 and 
926, to decision block 935. At this point, the workstation is 
either inquiring with its peer, in this case DHCP server 418 
in the LAN modem, as to the address of DHCP server or is 

50 requesting a DHCP address for itself from a DFCP server. 
Decision block 935 determines a type of the DHCP packet 
broadcast by the workstation. If the workstation has broad- 
cast a DHCP Discover packet, i.e., inquiring as to the 
identity of a DHCP server, then decision block 935 routes 

55 execution, via path 936, to block 940. This block, when 
executed, obtains an IP address from database 416 for DHCP 
server 418. Block 940 then sends this address to the work- 
station via a DHCP Offer packet Once this packet is sent, 
execution loops back, via paths 942 and 973, to decision 

60 block 910 pending receipt of the next packet. Now, if the 
type of the broadcast DHCP packet is a DHCP Request 
packet, specifying that the workstation has obtained an IP 
address of a DHCP server (in this case server 418) and is row 
requesting a dynamic IP address for itself, decision block 

65 935 routes execution, via path 938, to block 945. At this 
point, the LAN modem obtains and assigns a dynamic IP 
address to the workstation. In particular, block 945 queries 
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database 416, specifically Host list 1300 (see FIG. 13A) for 
an available entry. When such an entry is found, the corre- 
sponding IP address stored therein is read. Once this address 
has been obtained, block 950 executes to send this IP address 
to the workstation via a DHCP ACK (acknowledge) packet. 
After this packet is sent, execution proceeds to block 955 
which saves the name and Ethernet address of the 
workstation, obtained from the DHCP Request packet, in 
database 416 and specifically within this entry is Host list 
1300. As a result, this dynamic IP address is assigned to this 
particular workstation. Thereafter, execution exits from rou- 
tine 900 such that the LAN modem can return to normal 
operation. 

IE, however, the type of packet that has been broadcast by 
the workstation is an ARP (address resolution protocol) 
Request packet, then the workstation already has an IP 
address for itself, though it does not know the Ethernet 
address of its peer on the LAN, i.e., the LAN modem. It is 
immaterial to the LAN modem how or where that IP address 
originated. As will be seen, the LAN modem will utilize that 
IP address. In particular, an ARP Request packet can occur 
as a result of the browser requesting communication with a 
DNS server for eventual URL to IP address translation, or 
with a default gateway should the browser have the IP 
address for that URL, or with another local, workstation for 
other communication. In any case, the purpose of the ARP 
Request packet is for the workstation to obtain the physical 
Ethernet address of its peer, here the LAN modem, on the 
LAN — the workstation also has no knowledge as to the IP 
address of the LAN Modem. The ARP Request packet will 
respectively contain, as sending and destination IP 
addresses, the IP addresses of the sending workstation and of 
its target, i.e., its LAN peer or whatever the workstation 
believes that peer to be at the time, from which the work- 
station expects a response. Through use of the PRP protocol, 
only the target, recognizing its address as the destination, 
will respond to the ARP packet. For simplification, assume 
that the IP address of the sending workstation is denoted as 
IPy, while that of its target, i.e., here the LAN Modem, is 
designated as IP,. 

At this point, the destination IP address in the ARP 
Request packet will not, in all likelihood, match the factory 
default LP address of the LAN modem. As the reader will 
now appreciate, to initiate communication between the LAN 
modem and the workstation, the LAN modem will change 
its IP address to match that of the IP peer with which the 
workstation is attempting to communicate. In particular, if 
the browser is attempting to access a default web page and 
has broadcast an ARP Request packet, containing a desti- 
nation IP address of a gateway to which it assumes it is then 
physically connected, in order to obtain a physical network 
address of that gateway, the LAN modem will change its 
own IP address to match that of the gateway, as well as its 
subnet mask in order to place both the LAN modem and the 
workstation on the same subnet. Doing so will permit 
network communication to then occur between the LAN 
modem and the workstation. Subsequently, though not part 
of Initial Configuration process 900, once network commu- 
nication has been established between the LAN modem and 
the workstation, then in response to a subsequent request 
issued by the browser for a default web page, the LAN 
modem will download a file, constructed by web server 412, 
that contains a default home page of the LAN modem 
through which the user at the workstation can then initiate 
configuration of the LAN modem. 

Specifically, in response to the received ARP Request 
packet, decision block 920 routes execution, via paths 922 
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and 928, to block 960. This latter block sets the target IP 
address to IP„ and the source IP address to the directed 
broadcast IP address of the subnet and broadcasts an ARP 
Request packet back onto the LAN. The purpose of doing so 

5 is to elicit a response from any other network entity on the 
LAN having the same IP address as that sought by the 
workstation, such as another workstation — which represents 
an error condition. If such a network entity exists, it will 
respond to the ARP Request and supply its own Ethernet 

10 address. In addition, block 960 initiates a one-second timer. 
Execution then proceeds to decision block 965 to determine 
whether a packet has been received in response to the just 
broadcast ARP Request packet. If a response to this just 
broadcast ARP Request packet is received within the one- 

15 second rimin g interval, then an error condition has occurred. 
In this case, decision block 965 routes execution, via YES 
path 966, to block 970. This latter block stops the timer. 
Thereafter, execution loops back, via path 973, to decision 
block 910 to await receipt of the next incoming packet on the 

20 LAN. If, however, no such response packet is received, then 
decision block 965 routes execution, via NO path 968, to 
decision block 975. This latter block determines whether the 
one-second timing interval has elapsed. If this interval has 
not elapsed, then decision block 975 routes execution, via 

25 NO path 978, back to decision block 965 to continue testing 
for an occurrence of such a response during the remainder of 
this interval. Alternatively, if this interval elapses, then 
decision block 975 routes execution, via YES path 976, to 
block 980. Block 980, when executed, sets the IP address of 

30 the LAN modem to the target IP address in the ARP Request 
packet broadcast by the workstation; hence setting the IP 
address of the LAN modem to the IP address of a network 
peer from which the browser in the workstation expects a 
response. Thereafter, block 980 stores the IP address of the 

35 workstation, i.e., IP^, and its associated Ethernet address 
within database 416. Once this occurs, block 980, given 
these IP addresses of the LAN modem and the workstation, 
calculates an appropriate value of a subnet mask that places 
both the workstation and the LAN modem on the same 

40 subnet and which can accommodate a least number of, but 
no less than three, additional hosts. Block 980 then saves the 
calculated subnet mask in database 416 as the subnet mask 
of the LAN modem. Once this occurs, block 980 determines 
and saves at least three more IP addresses in the same subnet 

45 within database 416 to accommodate up to three additional 
workstations that can be connected to the LAN modem. The 
IP address assigned to the workstation and the three addi- 
tional addresses will each be stored as an IP address within 
a different host entry in Host list 1300. Thereafter, execution 

50 proceeds to block 985 which initiates a reset of the LAN 
Modem using its newly set IP address and subnet parameters 
just stored within database 416. Once the reset occurs, the 
LAN modem will no longer reside in its factory default state 
and will be able to communicate, over the LAN, with the 

55 workstation through the browser then executing therein, 
b. Source-based IP routing 

As discussed above, another inventive aspect of the LAN 
modem is its use of source-based routing. By routing packets 
based not only on the destination IP address of each packet 

60 but also and in accordance with our inventive teachings on 
its source IP address, the LAN modem can simultaneously 
accommodate multiple data connections to different ISPs — 
which is a result not possible with conventional routers. 
Consequently, through our inventive router, each of two 

65 users can advantageously be connected at the same time, 
through his(her) own workstation and the LAN modem, to 
his(ber) own preferred ISP. 
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The inventive source-based routing utilizes, as shown in 
FIG. 10, within ISDN router 306, two separate routing 
engines in succession, specifically primary router (PR) pro- 
cedure 1100 and secondary router (SR) procedure 1200 — 
both of which are implemented in software. Primary router 5 
procedure 1100 is implemented within TCP/IP process 425 
shown in FIG. 4B; secondary router procedure 1200 is 
implemented within secondary router process 450. 

Primary router procedure 1100, shown in FIG. 10, pro- 
vides conventional IP packet routing based on the destina- 10 
tion of each IP packet applied to it. Incoming packets are 
first applied, on a packet-by-packet basis, to primary router 
U00 which first routes each such packet, through 
Destination-Based Routing Table 432 (not specifically 
shown in this figure; see FIG. 4B), based on its destination 15 
IP address. Packets arrive at the primary router from three 
sources: from the LAN, from the local applications or from 
the secondary router procedure. For each such packet, the 
primary router has three basic routing choices: (a) to the 
LAN, e.g., to a workstation thereon; (b) based on a protocol 20 
field in the packet, to one of local applications 1000, 
including Telnet 411, HTTP 415, DHCP server 418 or DNS 
server 421 (all of which have been discussed above); or (c) 
lastly, for all other packet destinations, to the secondary 
router. 25 

As for the secondary router procedure, incoming packets 
arrive at it either from the remote network accessible 
through ISDN line 40 or from the primary router. The 
secondary router procedure routes all packets incoming from 
the remote network to the primary router. Alternatively and 30 
essentially, each incoming packet arriving from the primary 
router is routed by the secondary router, as discussed in 
detail below in conjunction with Secondary Router Proce- 
dure 1200 shown in FIGS. 12A-12D, based on its source IP 
address and specification of permissible network service 35 
providers, to one of those providers. If a B-channel ISDN 
data connection is not then established to that provider, 
secondary router process 450 (see FIG. 4B) will instruct 
other processes, such as Call Control process 461, in the 
manner discussed above, to establish the connection over an 40 
available B-channel and, once the connection is so 
established, route the packet accordingly. 

As discussed above, to accomplish source-based routing, 
secondary router 450 maintains and uses entries in database 
416; specifically, Host list 1300 and Network Service Pro- 45 
vider list. 1350, both stored therein (see FIGS. 13A and 
13B). The manner through which these lists are used for 
source-based IP routing will be discussed in detail below in 
conjunction with Secondary Router procedure 1200 shown 
in FIGS. 12A-12D. 50 

FIG. 11 depicts a flowchart of Primary Router procedure 
1100. As shown, upon entry into procedure 1100, execution 
first proceeds to block 1110. This block, when executed, 
receives an incoming packet from the LAN, one of local 
applications 1000 (see FIG. 4B) or from the secondary 55 
router procedure 1200. Once the packet is received, block 
1120, shown in FIG. 11, executes to determine the destina- 
tion IP address of that packet Thereafter, based on the 
destination IP address, decision block 1130, next executed, 
routes execution to one of three paths depending on this 60 
address. If the IP address specifies a workstation (host) on 
the LAN, then decision block 1130 routes execution, via 
path 1135, to block 1140. This latter block, through access- 
ing entry 1352 in Destination-Based Routing Table 432 (see 
FIG. 13Q, sends the received packet out to the LAN to the 65 
appropriate host thereon among workstations 10 (see FIG. 
3). Alternatively, if the destination IP address matches that of 
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the LAN modem and a protocol field specifies one of local 
applications 1000, then, as shown in FIG. 11, decision block 
1130 routes execution, via path 1135, to block 1150. This 
latter block routes the received packet to the appropriate 
local application. Lastly, if the destination IP address of the 
received packet specifies anything other than a host on the 
LAN or the LAN modem itself, then decision block 1130 
routes execution, via path 1135, to block 1160. This latter 
block, through accessing entry 1354 in Destination-Based 
Routing Table 432 (see FIG. 13C), routes the received 
packet to secondary router procedure 1200 for eventual 
carriage, as specified in this entry over an ISDN connection 
to a remote network. Once block 1140, 1150 or 1160 has 
fully executed to appropriately route the received packet 
based on its destination IP, address, execution loops back, 
via path 1165, to await the next incoming packet 

FIGS. 12A-12D collectively depict a flowchart of Sec- 
ondary Router procedure 1200; the correct alignment of 
these figures being shown in FIG. 12. 

As shown, upon entry into procedure 1200, execution first 
proceeds to block 1203 which, when executed, receives an 
incoming packet. As discussed above, the incoming packet 
can arise from either the WAN, connected to the LAN 
modem through an ISDN connection, or locally, via Primary 
Router procedure 1100. Thereafter, block 1206 is executed 
to check the destination IP address of that packet. Decision 
block 1210 then directs the packet accordingly based on its 
destination IP address. In particular, if the packet is incom- 
ing from the WAN, i.e., the destination IP of the packet is 
either for the LAN modem itself or a local host on the LAN, 
then decision block 1210 routes execution, via path 1212, to 
block 1215. This latter block, when executed, sends the 
incoming packet onward to Primary Router procedure 1100 
for routing to the appropriate destination. Thereafter, execu- 
tion loops back, via paths 1216 and 1299, to block 1203 to 
await the next incoming packet. Depending upon the con- 
figuration of the LAN modem, packets may have to flow 
through IP/Port Number Translation (NAI} module 435 for 
IP address/port number translations; for simplification, pro- 
cess 435 has been omitted from the present discussion. 

Alternatively, if the packet is incoming from Primary 
Router procedure 1100, i.e., the packet is destined for the 
WAN, then decision block 1210 routes execution, via path 
1214, to block 1218. This latter block obtains, from the 
packet itself, an IP address of the source of the packet. 
Execution then proceeds to block 1220, which searches 
through host list 1300 in database 416 (see FIG. 13A), to 
locate an entry therein that has an IP address that matches the 
source IP address of the incoming packet. Once this opera- 
tion completes, execution proceeds to decision block 1223. 
Based on the results of the search, this decision block 
determines whether the packet has arrived from a valid 
source, i.e., whether the source IP address of the packet 
matches either an IP address contained within the Host list 
1300 or the IP address of the LAN modem itself. If no such 
match is found, then the packet, for some reason, appears to 
originate from an invalid source and hence is erroneous. In 
that case, decision block 1223 routes execution, via YES 
path 1226, to block 1228. This latter block, when executed, 
merely discards the incoming packet Thereafter, execution 
loops back, via paths 1229 and 1299, to block 1203 to await 
the next incoming packet 

If, however, the incoming packet originates from a valid 
source, such as a host on the LAN or the LAN modem itself, 
then decision block 1223 routes execution, via NO path 
1224, to decision block 1230. This latter decision block 
determines, whether that host has manually established an 
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existing ISDN connection. If this is the case, then the packet 
is simply routed over that connection to a remote network. 
Specifically, decision block 1230 routes execution, via YES 
path 1234, to block 1235 which, when executed, routes the 
packet over this particular ISDN connection then in use. 
Thereafter, execution loops back, via paths 1236 and 1299, 
to block 1203 to await the next incoming packet. 

Alternatively, if a local host has not manually established 
an ISDN connection, then decision block 1230 routes 
execution, via NO path 1232, to block 1237. Decision block 
1237 determines, from the source IP address in that packet 
and previously obtained through execution of block 1218, 
whether the incoming packet originates with the LAN 
modem itself; if not, then the packet originated with a host 
on the LAN. The LAN modem does not initiate a connection 
to a remote network. For any packet the LAN modem 
generates itself, the LAN modem merely sends that packet 
to an appropriate network service provider over an existing 
connection. However, for a packet originating with a host, 
the LAN modem selects an appropriate network service 
provider, and if a connection is not then established thereto, 
establishes such a network connection. 

If the incoming packet does not emanate from the LAN 
modem itself, then execution proceeds, via NO path 1239, 
emanating from decision block 1237, to block 1240. 

Through execution of blocks 1240-1256, the network 
service provider that is to carry the incoming packet, origi- 
nating with a host on the LAN, will be selected. The order 
through which a network service provider will be selected 
for receiving the incoming packet is first to a network 
service provider that has a matching IP address to the 
destination address in the incoming packet; then, if no such 
network service provider then exists, to a network service 
provider that is an Internet service provider; and finally, if 
neither of the preceding network service providers exists, to 
a network service provider for a private network that pro- 
vides Internet access. If an ISDN connection is not then 
established to the selected provider, such a connection will 
then be established. Thereafter, the incoming packet will be 
routed to the selected network service provider either over 
that newly established connection or a previously estab- 
lished and existing connection thereto. 

In particular, block 1240, when executed, accesses Host 
list 1300 to determine, given the source IP address of the 
packet, which network service providers can be used by the 
corresponding host, i.e., which SPs are permitted to provide 
network access to that host. Once these providers have been 
determined, block 1242 executes. This block searches 
through the entries for these permitted network service 
providers in Network Service Provider list 1350 to deter- 
mine if a Destination IP address in the incoming packet 
matches any network IP address (stored within the network 
ID information in each entry in this list) for these providers. 
If such a match is found, decision block 1243 routes 
execution, via YES path 1244 and path 1260, to block 1257. 
Alternatively, if such a match does not exist, then decision 
block 1243 routes execution, via NO path 1246, to block 
1248. This latter block, searches through Network Service 
Provider list 1350 to determine, for those network service 
providers permitted to render network access to the host that 
issued the packet, whether such a network service provider 
is an ISP. If such a match is found, decision block 1250 
routes execution, via YES path 1251 and path 1260, to block 
1264. Alternatively, if such a match does not exist, then 
decision block 1250 routes execution, via NO path 1252, to 
block 1254. This latter block, searches through Network 
Service Provider list 1350 to determine, for those network 
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service providers permitted to rentier network access to the ~ 
host that issued the packet, whether such a network service 
provider provides access to a private network that affords 
Internet access. If, at this point, such a match is not found, 

5 decision block 1256 routes execution, via NO path 1258, to 
block 1261. Block 1261, when executed, merely discards the 
incoming packet. Thereafter, execution loops back, via paths 
1262 and 1299, to block 1203 to await the next incoming 
packet. However, if a match is found through execution of 

10 decision block 1256, this block then routes execution, via 
YES path 1257, to block 1264. 

Blocks 1264-1274 collectively determine whether an 
ISDN connection is established for the network service 
provider, selected through execution of blocks 1240-1256, 

is and if not, to establish such a connection, and finally to route 
the incoming packet, that originated with a host on the LAN, 
to the selected network service provider over this connec- 
tion. 

In particular, block 1264, by querying Source-Based 

20 Routing Table 446 (see FIG. 4B) accesses an appropriate 
entry for the host that originated the incoming packet to 
determine whether an ISDN call is currently established to 
the selected network service provider. If an ISDN call is 
established to this provider, then decision block 1266, shown 

25 in FIGS. 12A-12D, routes execution, via YES path 1268, to 
block 1270. This latter block, when executed, routes the 
incoming packet over this established connection to the 
selected network service provider. Thereafter, execution 
loops back, via paths 1272 and 1299, to block 1203 to await 

30 the next incoming packet Alternatively, if an ISDN con- 
nection is not established between the LAN modem and the 
selected network service provider, then decision block 1266 
routes execution, via NO path 1267, to block 1273. This 
latter block, when executed, queues the incoming packet in 

35 a waiting queue until such time as an ISDN connection can 
be established to the selected network service provider. Once 
the packet is queued, then block 1274 executes to begin 
establishing, through Call Control process 461 (see FIG. 4B; 
with the inter-process communication for establishing such 

40 a connection being shown in FIG. 5) an ISDN connection to 
this network service provider. Once this connection has been 
fully established, including after all the PPP protocols have 
been negotiated, then the incoming packet is removed from 
the waiting queue and routed over the connection to the 

45 selected network service provider. Thereafter, execution 
loops back, via paths 1275 and 1299, to block 1203 to await 
the next incoming packet. 

Now, if the incoming packet originated with the LAN 
modem, rather than a host on the LAN, then decision block 

50 1237 directs execution via YES path 1238, to block 1276. 
Blocks 1276-1293 select an appropriate network service 
provider, with which the LAN modem has established a 
current ISDN connection, to which that packet is then 
routed. Blocks 1276-1293 are essentially the same as blocks 

55 1240-1256. 

In any event and in particular, block 1276, when executed, 
searches through the entries for all network service provid- 
ers in Network Service Provider list 1350 to determine if a 
Destination IP address in the incoming packet matches any 

60 network IP address (stored within the network ID informa- 
tion in each entry in this list) for these providers. If such a 
match is found, decision block 1277 routes execution, via 
YES path 1278 and paths 1281 and 1288, to block 1292. 
Alternatively, if such a match does not exist, then decision 

65 block 1277 routes execution, via NO path 1279, to block 
1280. This latter block, searches through Network Service 
Provider list 1350 to determine, for those network service 
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providers permitted to reader network access to the host that 
issued the packet, whether such a network service provider 
is ao ISP. If such a match is found, decision block 1282 
routes execution, via YES path 1283 and path 1281, to block 
1292. Alternatively, if such a match does not exist, then 
decision block 1282 routes execution, via NO path 1284, to 
block 1285. This latter block, searches through Network 
Service Provider list 1350 to determine, for those network 
service providers permitted to render network access to the 
host that issued the packet, whether such a network service 
provider provides access to a private network that affords 
Internet access. If, at this point, such a match is not found, 
decision block 1286 routes execution, via NO path 1287, to 
block 1289. Block 1289, when executed, merely discards the 
incoming packet. Thereafter, execution loops back, via paths 
1290 and 1299, to block 1203 to await the next incoming 
packet. However, if a match is found through execution of 
decision block 1286, then this block routes execution, via 
YES path 1288, to block 1292. 

Thereafter, execution proceeds to blocks 1292-1296 to 
route the incoming packet, originating from the LAN 
modem, to the selected network service provider. 

In particular, block 1292, by querying Source-Based 
Routing Table 446 (see FIG. 4B), determines whether an 
ISDN call is currently established to the selected network 
service provider. If an ISDN call is established to this 
provider, then decision block 1293 routes execution, via 
YES path 1294, to block 1296. This latter block, when 
executed, routes the incoming packet over this established 
connection to the selected network service provider. 
Thereafter, execution loops back, via paths 1297 and 1299, 
to block 1203 to await the next incoming packet. 
Alternatively, if an ISDN connection is not established 
between the LAN modem and the selected network service 
provider, then decision block 1293 routes execution, via NO 
path 1295, to block 1298. This latter block, when executed, 
merely discards the packet; inasmuch as the LAN modem 
does not initiate an ISDN call to a remote network service 
provider for any packet that originated with the LAN 
modem. Thereafter, execution loops back, via paths 1299, to 
block 1203 to await the next incoming packet. 

c. Internal DNS and DHCP servers and Interception of 
Remote DNS Request for Error Handling 

As discussed above, the LAN modem contains internal 
co-operating DHCP and DNS servers that are integrated 
with routing and call management processes, all utilizing a 
shared database, Le., database 416 (see FIG. 4B). 

Use of the internal DNS server provides local name-to- 
address resolution such that, for user convenience and 
simplicity, each workstation on the LAN can be addressed in 
terms of its machine name rather than its IP address. 
Furthermore, the DNS server, by using a shared database 
with the DHCP server, operates transparently of any user to 
acquire machine names of all the workstations connected to 
the LAN and then provide suitable machine name to IP 
address resolution, as needed, for all communication 
between the LAN modem and these workstations as well as 
between any pair of workstations themselves. In addition, 
the DNS server given a DNS query, will determine, based on 
the source of the query, i.e., which specific workstation 
generated it, and the destination to which the query is 
directed (e.g., another host on the LAN as identified by the 
machine name of the host, the LAN modem itself or a 
remote network), the DNS server to which the query is to be 
routed and will then route the query accordingly to that 
server. As such, the LAN modem hides from a host the 
selection of the DNS server that is utilized in conjunction 
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with a remote network accessible through a given network 
service provider and which will be used in a given instance. 
Doing so significantly simplifies the use of the DNS in each 
workstation connected to the LAN modem, and further 
5 facilitates use of either static or dynamic IP addressing for 
each workstation. In addition, the DHCP server provides the 
IP address, subnet mask, gateway and DNS server addresses 
to the local workstations, thereby eliminating any need to 
manually configure and administer these items at each 
10 workstation. Furthermore, any workstation is always 
assigned the same IP address from the DHCP server, rather 
than having its IP address change from session to session, as 
would normally occur with dynamic IP addressing. 
Consequently, the user profile associated with each work- 
station can be easily maintained and identified using its host 
IP address, and the number of workstations, that are simul- 
taneously allowed to use the LAN modem, can be very 
easily controlled. 

FIG. 14 depicts a flowchart of DHCP Induced IP Address 
20 Request procedure 1400. Procedure 1400 provides a host IP 
address in response to a DHCP Request packet in order to 
effectuate machine name to IP address resolution for an 
additional workstation (host) that has been connected to the 
LAN 

Specifically, upon entry into procedure 1400, execution 
first proceeds to decision block 1410. This block, when 
executed, determines whether the Ethernet address of the 
additional host equals that of one of the hosts in Host list 
1300 (see FIG. 13A). If this address matches the Ethernet 
address in the host list, i.e., indicative of this host already 
being connected to the LAN and having an IP address 
allocated to it in the Host list, then, as shown in FIG. 14, 
decision block 1410 routes execution, via YES path 1413, to 
block 1420. This latter block, when executed, tests whether 
the machine name is specified in the DHCP Request packet 
and whether that machine name is not the same as that in the 
host entry in the Host list. In that regard, if a host is not 
configured to have a machine name, then the DHCP Request 
packet will not contain a machine name field. Moreover, the 
machine name in the host entry is only changed if the 
machine name in the DHCP Request packet differs from that 
in the entry. If such a different machine name is specified in 
the DHCP Request packet, then decision block 1420 routes 
execution, via YES path 1422, to block 1425; otherwise, 
execution is routed, via NO path 1424 to block 1430. Block 
1425, when executed, replaces the machine name in the Host 
list for this particular host, at this point typically being a 
default value of "UnknownPC_x" (where x is a numeral 
between, illustratively, 1-4 for the preferred embodiment; 
so see FIG. 13 A), with the host name, Le., machine name, 
provided in the DHCP Request packet. Execution then 
proceeds to block 1430, shown in FIG. 14, which assigns a 
Host IP address to this particular host from the IP address 
stored in the entry for this host in Host list 1300 and provides 
that IP address back to this host, via a DHCP ACK 
(acknowledge) packet. Once this occurs, execution then 
exits from procedure 1400. 

Alternatively, if no entry in the Host list contains the 
Ethernet address of the additional host, then decision block 
1410 routes execution, via NO path 1417, to decision block 
1440. This latter decision block determines from the number 
of entries in Host list 1300 whether the host list can 
accommodate another entry, i.e., whether less than four 
workstations (or other network devices) for the preferred 
embodiment have been connected to the LAN and config- 
ured for network access through the LAN modem. If do free 
host entry exists within the host list, then execution merely 
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exits, via NO path 1442, from procedure 1400. This adbT- Alternatively, if the host name- in the DNS query parket 

tional workstation simply can not be accommodated and does not match that of any host on the LAN, then decision 

represents an error condition, in that now more than a block 1512 routes execution, via NO path 1514, to block 

maximum number of workstations (and network devices) 1520. This latter block, when executed, extracts the source 

(the maximum being four such devices in the preferred 5 jp address from the DNS query packet, i.e., the IP address 

embodiment) are connected to the LAN through, for of the particular host on the LAN that originated this packet, 

example, a hub that is connected to one port of the LAN. Thereafter, block 1523, given this source DP address, 

However, if a free entry then exists in the host list, then accesses Host list 1300 for an entry for this particular host 

decision block 1440 directs execution, via YES path 1444, mis access completes, execution proceeds to decision 

to oedsimi block 1445. This latter block determines whether M ^ 1526 ^ dedsion block delermines whethcr a 

the DHCP Request packet specifies a machine name Only ^ exis ^ • whether a host entry was retrieved 

jch a name ^specified wUl an entry in to Host to be response to the source IP address. If 

updated to reflect that name. If the DHCP Request packet . . . ...... m , , 

specifies a machine name, then decision block 1440 routes no °°st exists with this source IP address, then an 
execution, via YES path 1446, to block 1450; otherwise, unauthorized host on the LAN has been detected, 
execution is routed, via NO path 1448, to block 1460. Block Accordingly, decision block 1526 routes execution, via NO 
1450 stores information regarding this additional host into P alh 1527 > lo block ^ whlCD > | n t"™* discards the DNS 
the host list, in order to accommodate this additional host In query packet. Execution then exits from procedure 1500. 
particular, block 1450, when executed, replaces the machine However, if a host entry was found, i.e., the host on the LAN 
name in the Host list for the additional host, at this point which generated the DNS query packet is valid, then deci- 
typically being a default value of "UnknownPC _x", with 20 sion block 1526 routes execution, via YES path 1528, to 
the host name, i.e., machine name, provided in the DHCP decision block 1533. This latter decision block determines 
Request packet. Execution then proceeds to block 1460 whether that particular host has manually established an 
which replaces the Ethernet address (at this point typically existing ISDN connection. If this is the case, then the packet 
being a default address of zero, as shown in FIG. 13A) in the is simply routed over that connection to a remote network, 
entry in the Host list with the actual Ethernet address of this 25 Specifically, decision block 1533 routes execution, via YES 
additional host as supplied in the DHCP Request packet. path 1534, to block 1538 which, when executed, changes the 
Thereafter, block 1470, shown in FIG. 14, executes to assign IP address of the packet by substituting the IP address of a 
the IP address of the free host entry to the requesting host by remote DNS server associated with that network into the 
providing that IP address to the host, via a DHCP ACK packet as its destination IP address. Thereafter, block 15:38 
(acknowledge) packet. Once this occurs, execution then 30 routes the resulting packet over this particular ISDN con- 
exits from procedure 1400. nection then in use. Execution then exits from procedure 

FIGS. 15A-15D collectively depict a flowchart of DNS 1500. 

Induced IP Address Request procedure 1500; the correct Alternatively, if a local host has not manually established 

alignment of the drawing sheets for these figures is shown in an ISDN connection, then decision block 1533 routes 

FIG. 15. Procedure 1500 implements two basic functions; 35 execution, via NO path 1535, to block 1540. Through 

namely, providing an IP address of a proper DNS server in execution of blocks 1540-1560 (similar to execution of 

response to either a DNS Query packet from any host blocks 1240-1256 in procedure 1200 shown in FIGS, 

connected to the LAN, and properly handling expiration of 12A-12D), the network service provider that is to carry the 

the idle timeout interval. DNS query packet will be selected. The order through which 

Specifically, upon entry into procedure 1500 execution 40 a network service provider will be selected for receiving this 

first proceeds to decision block 1502 to test an incoming packet is first to a network service provider that has a 

packet. If this packet is a DNS query packet, then decision matching domain name to that in the incoming packet; then, 

block 1502 routes execution, via YES path 1504, to decision if no such network service provider then exists, to a network 

block 1506. This latter decision block determines whether service provider that is an Internet service provider; and 

the host name in the DNS query packet matches that of the 45 finally, if neither of the preceding network service providers 

LAN modem, i.e., a workstation is querying the LAN exists, to a network service provider for a private network 

modem to specify the address for its internal DNS server. If that provides Internet access. If an ISDN connection is not 

the names match, then execution proceeds, via YES path then established to the selected provider, such a connection 

1508, to block 1510. This latter block, when executed, forms will then be established. Thereafter, the DNS query packet 

a DNS Reply packet containing the IP address of the LAN 50 will be routed, with a changed destination IP address, to the 

modem itself, and then sends that packet to TCP/IP process selected network service provider, either over that newly 

425 for eventual routing, via the LAN, to the requesting established connection or a previously established and exist- 

local host (workstation). Execution then exits from proce- ing connection thereto. 

dure 1500. Alternatively, if the host name in the DNS query In particular, block 1540, when executed, accesses Host 

packet does not match that of the LAN modem, then 55 list 1300 to determine, given the host entry, which network 

decision block 1506 routes execution, via NO path 1507, to service providers can be used by the corresponding host, i.e., 

decision block 1512. This latter decision block determines, which (SPs) are permitted to provide network access to that 

through accessing the host list (see FIG. 13A) whether the hosL Once these providers have been determined, block 

host name in the DNS query packet matches the host name 1543 executes. This block searches through the entries for 

of any of the workstations on the LAN. If such a match is 60 these permitted network service providers in Network Ser- 

found, then execution proceeds, via YES path 1513 shown vice Provider list 1350 to determine if a domain name in the 

in FIG. 15A, to block 1516. This latter block, when DNS query packet matches the domain name (stored within 

executed, forms a DNS Reply packet containing the IP the network ID information in the each entry in this list) in 

address of that particular host on the LAN, and then sends the entries for any of these providers which are private 

that packet to TCP/IP process 425 for eventual routing, via 65 networks. If such a match is found, decision block 1546 

the LAN, to the requesting local host (workstation). Execu- routes execution, via YES path 1547 and path 1565, to block 

tion then exits from procedure 1500. 1566. Alternatively, if such a match does not exist, then 
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decision block 1546 routes execution, via NO path 1548, to 
block 1550. This latter block, searches through Network 
Service Provider list 1350 to determine, for those network 
service providers permitted too render network access to the 
host that issued the packet, such a provider that is an ISP. If 
such a match is found, decision block 1553 routes execution, 
via YES path 1554 and path 1565, to block 1566. 
Alternatively, if such a match does not exist, then decision 
block 1553 routes execution, via NO path 1555, to block 
1558. This latter block, searches through Network Service 
Provider list 1350 to determine, for those network service 
providers permitted to render network access to the host that 
issued the DNS query packet, whether such a network 
service provider provides access to a private network that 
affords Internet access. If a match is found, block 1560 
routes execution, via YES path 1562 and 1565 to 1566. If, 
at this point, such a match is not found, decision block 1560 
routes execution, via NO path 1561, to block 1564. Block 
1564, when executed, sends a DNS reply packet, to the local 
host, containing an error indication specifying that a DNS 
server can not be found. Thereafter, execution exits from 
procedure 1500. 

Blocks 1566-1578 collectively determine whether an 
ISDN connection is established for the network service 
provider, selected through execution of blocks 1540-1560, 
and if not, to establish such a connection, and finally to route 
the DNS query packet to the DNS server at the selected 
network service provider over this connection. 

In particular, block 1566 by querying Source-Based Rout- 
ing Table 446 (see FIG. 4B) accesses an appropriate entry 
therein for the host that originated the DNS query to 
determine whether an ISDN call is currently established to 
the selected network service provider. If an ISDN call is 
established to this provider, then decision block 1570, shown 
in FIGS. 15A-15D, routes execution, via YES path 1571, to 
block 1574. This latter block, when executed, accesses from 
Network Service Provider (SP) list 1350 the IP address of 
the remote DNS server for this particular network service 
provider. Once this address (denoted "DstnIP") is accessed, 
this block then substitutes this address as the destination IP 
address, in lieu of the address of the LAN modem, into the 
DNS query packet. Thereafter, block 1576 executes to send 
the resulting DNS query packet, now containing the IP 
address of the remote DNS server, to TCP/IP process 425 for 
routing to the selected network service provider and spe- 
cifically the remote DNS server associated therewith. 
Execution then exits from procedure 1500. 

Alternatively, if an ISDN connection is not established 
between the LAN modem and the selected network service 
provider, then decision block 1570 routes execution, via NO 
path 1572, to block 1577. This latter block, when executed, 
queues the DNS query packet in a waiting queue until such 
time when an ISDN connection can be established to the 
selected network service provider. Once the packet is 
queued, then block 1578 executes to begin establishing, 
through Call Control process 461 (see FIG. 4B; with the 
inter-process communication for establishing such a con- 
nection being shown in FIG. 6) an ISDN connection to this 
network service provider. Execution then exits from proce- 
dure 1500. 

Now, if the incoming packet is not a DNS query packet, 
then decision block 1502 routes execution, via NO path 
1503, to decision block 1580. This latter decision block tests 
whether the packet contains a message from secondary 
router 450, i.e., indicative of whether a requested ISDN call 
to the selected network service provider was successfully 
established by the LAN modem or not. If the packet contains 
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such a message, then decision block 1580 routes execution, 
via YES path 1582, to decision block 1583. 

If the call was attempted but for whatever reason, could 
not be established to the selected network service provider, 

5 then decision block 1583 routes execution, via NO path 
1584, to decision block 1586. This latter decision block 
determines whether the secondary router provided an error 
message regarding this attempted call. If no such error 
message was received, then execution exits from routine 

10 1500, via NO path 1587 emanating from decision block 
1586. It, however, secondary router 450 provided an error 
message, such as an indication of a busy connection or that 
a B -channel was not then available and hence the call could 
not be placed, execution proceeds, via YES path 1588, to 

is block 1590. Block 1590 sends a DNS reply packet back to 
the requesting host but with the IP address of the LAN 
modem itself as the IP address of the remote DNS server. 
Thereafter, block 1591 executes to set a shared (global) 
variable maintained within database 416 to signify the 

20 particular failure, such as, e.g., a busy connection, that then 
prevented the call from being established. Execution then 
exits from procedure 1500. 

Once the browser in the host, that issued the DNS query 
packet, receives this DNS reply packet, that browser will 

25 then issue a request to what it believes to be the remote DNS 
server to translate the domain name of a desired web server 
(typically that which stores a default web page defined in the 
browser) and then fetch a particular web page (e.g., the 
default page) therefrom. Though the browser will naturally 

30 assume that the IP address it received in the reply packet is 
that of a remote DNS server, in actuality it is that of the LAN 
modem itself — in effect the LAN modem has intercepted the 
DNS request from the host, i.e., a remote DNS server. 
TCP/IP process 425 (see FIG. 4B) within the LAN modem, 

35 in receiving this domain name translation request, will route 
this request to DNS server 421 which will return the IP 
address of the LAN modem itself. Once this occurs and the 
host issues a request to fetch the default page, web server 
416, in response to receiving this request as routed to it by 

40 TCP/IP process 425, will test the shared (global) variable 
and determine, by the value of this variable, that an error 
condition has just occurred, and specifically the reason why 
an ISDN connection could not be completed then. 
Consequently, the web server, rather than returning a 

45 requested default page to the browser, will dynamically 
construct, through insertion of error-specific code 
segment(s) into a predefined page template, a web page that 
specifies an error condition has occurred, i.e., that an ISDN 
connection could not be established, and the specific reason 

50 why, e.g., the destination was busy or no B-channel was then 
available to accommodate the connection and then down- 
load this page, via TCP/IP process 425, to the host. The 
inventive manner through which this page is dynamically 
constructed to depict an error condition is discussed in detail 

55 below in conjunction with FIGS. 22-26. 

Alternatively, if the call was successfully established, 
including negotiation of all PPP protocols as appropriate, 
then decision block 1583, shown in FIGS. 15A-15D, routes 
execution, via YES path 1585, to block 1592. This latter 

60 block, when executed, stops the idle timeout timer, if it is 
then running. As noted above, an error condition arises if an 
ISDN connection can not be established within the idle 
timeout period. Once the timer is stopped, then block 1593 
is executed Block 1593 accesses, from Network Service 

65 Provider (SP) list 1350, the IP address (denoted "DstnIP") of 
the remote DNS server for this particular network service 
provider. Thereafter, this block removes the DNS query 
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packet from the waiting queue. Once this occurs, block 1593 
substitutes the IP address ("DstnlP") of the remote DNS 
server as the destination IP address, in lieu of the address of 
the LAN modem, into the DNS query packet Thereafter, 
block 1594 sends the resulting DNS query packet, now 
containing the IP address of the remote DNS server, to 
TCP/IP process 425 for routing to the selected network 
service provider and specifically the remote DNS server 
associated therewith. Execution then exits from procedure 
1500. 

If, alternatively, the incoming packet is neither a DNS 
query packet nor contains a message from secondary router 
450, then decision block 1580 routes execution, via NO path 
1581, to decision block 1595. This latter decision block 
determines whether the packet indicates that the idle timeout 
interval has just elapsed, indicative that an ISDN call could 
not be completed during an allotted idle time interval 
(typically 30 seconds, though subject to change by a user at 
a host during configuration of the LAN modem). If the 
incoming packet does not indicate such a timeout condition, 
then execution simply exits from procedure 1500, via NO 
path 1596 emanating from decision block 1595. 
Alternatively, if such a timeout condition occurred, then 
decision block 1595 routes execution, via YES path 1597, to 
block 1598. For every queued DNS query packet from the 
local host, block 1598 sends a DNS reply packet containing 
a suitable error message back to that host. Once the reply 
packet(s) has been so sent, execution exits from procedure 
1500. 

As noted above, any host (workstation) on the LAN is 
always assigned the same IP address from the DHCP server 
within the LAN modem, rather than having the IP address 
possibly change from session to session, as would normally 
occur with dynamic IP addressing. This is accomplished, 
within DHCP server 418 (see FIG. 4B) located within the 
LAN Modem, by simply ignoring a request from the host., 
i.e., through an IP Address Release message issued by the 
DHCP protocol in the host, to release any IP address 
previously assigned to that hosL Hence, once an association 
is established within the host list between a host and a given 
Ethernet address, that host as it re-establishes a network 
connection to the LAM modem is always assigned the same 
dynamic IP address — absent any intervening loss of power 
to the LAN modem which, upon a subsequent power-on 
reset, re-initializee the LAN modem and sets entries in the 
host list back to their default values shown in FIG. 13A. By 
maintaining the same IP address assignments for the indi- 
vidual workstations as, over the course of time, new host 
sessions and network connections are established therefor 
over the LAN, the user profile associated with each 
workstation, as well as the host list itself, will be subject to 
far fewer updates than if these addresses were to regularly 
change and this information constantly modified to track 
these changes, and is thus easier to access and administer. 
This, in turn, advantageously simplifies the underlying 
administrative code and saves processing time. Moreover, 
the number of workstations that is simultaneously allowed to 
use the LAN modem at any one time can be very easily 
controlled by merely counting the number of entries then in 
use in the host list, 
d Program storage and firmware integrity 
Rash memory provides non-volatile data storage, though 
its access speed is relatively slow compared to DRAM 372. 
Consequently, all the program code and data values for the 
LAN modem, as discussed above, are stored in flash 
memory 376 shown in FIG. 3. During a power-on boot 
phase, the boot program executes to copy the executable 
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program code from the flash memory into the DRAM, from 
which this code is then read and executed. 

Conventionally speaking, information stored within vola- 
tile memory, such as DRAM, is subject to being corrupted 

5 from transient phenomena, such as power surges and the 
like. In that regard, if the contents of a location in DRAM 
372 that stores part of a program then being executed, were 
to become corrupted, errant program execution may result to 
the ultimate detriment of any then on-going network com- 

10 muni cation between a host and a remote network. To prevent 
such errant operation, the LAN modem strictly controls 
write access to the flash memory through use of a key-based 
software implemented lock. In addition, the LAN modem 
continually checks, on a location-by-location basis, the 

15 executable code stored within DRAM against the same 
executable code stored in the flash memory for any discrep- 
ancies therebetween and, should any such discrepancy be 
found, corrects, by over-writing, the contents of the location 
in the DRAM with the contents of the corresponding pro- 

20 gram location in the flash memory. Through these two 
processes, the integrity of the contents of the flash is assured 
by substantially reducing any likelihood that the mode of the 
flash memory can be erroneously changed from read-only to 
read/write. The integrity of the executable code (firmware) 

25 in the DRAM is maintained by continually and repeatedly 
comparing and correcting it to identically reflect that stored 
within the flash memory. This process of continual compari- 
son and correction continually executes as a fully preempt- 
able background process during those intervals that would 

30 otherwise constitute idle processing time for CPU 330 (see 
FIG. 3). 

FIG. 16 depicts a flowchart of Firmware Upgrade (FU) 
process 402. This particular process, which forms part of 
software 400 shown in FIG. 4B all of which executes in 

35 foreground, limits write access to the flash memory on a 
key-controlled basis. 

Specifically, process 402 is spawned by Configuration 
Manager 401 upon system reset, typically in response to a 
power-on reset. Upon entry into this process, execution 

40 proceeds to block 1610, shown in FIG. 16, which places this 
process in an initial state. During normal operation of the 
LAN modem, process 1610 will remain in this state at all 
times with exception of rather brief intervals, no longer than 
illustratively five minutes, during which the flash memory is 

45 set to a write mode to permit an actual upgrade of the 
firmware stored therein to be initiated from a remote file 
server. In this initial state, the firmware upgrade process is 
not running, contents of a write access key register are 
cleared to zero, and flash memory 376 is set to a read-only 

50 mode. The write access key itself is stored within the flash 
memory as a predefined unique 32-bit (four-byte) value. Its 
particular value, assigned during manufacture, is not critical, 
though preferably it should be a random or pseudo-random 
number to ensure its uniqueness, i.e., a value that has an 

55 extremely high probability of not naturally occurring or 
arising from an errant phenomena. As will be discussed 
below, in order to change the mode of the flash memory from 
read-only to read/write, the value of this key must be copied 
from its original location in flash memory into a write access 

60 key register in DRAM. Then, if and only if the value of the 
key as stored in this register matches the key in its original 
location in flash memory, the mode of the flash memory will 
be changed from read-only to read/write. If a proper value 
for the key is selected during manufacture, then the likeli- 

65 hood that an errant process will set, i.e., corrupt, the contents 
of the 32-bit key register in such a manner that the contents 
of this register will exactly match the key stored in flash 
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memory is less than 1 in a billion, thus assuring' that the the- flash" memory, therrexccatiun proceeds, aria YES path 

integrity of the code stored in the flash memory is main- 1654, to block 1655. Block 1655, when executed, changes 

tained to a very substantial degree, typically to an error level the mode of the flash memory from read-only to read/write, 

of less than one part in a billion. Thereafter, execution proceeds to block 1660 which updates 

After block 1610 has been executed, decision block 1620 5 the contents of flash memory 376 with replacement program 
periodically determines whether a firmware upgrade process code received, via TCP/TP process 425, from a host or 
has been invoked. If this process has not been invoked, then remote client. Decision block 1670 tests whether the firm- 
decision block 1620 loops back execution, via NO path 1622 ware upgrade is complete. If the upgrade has not completed, 
and path 1676, back to block 1610, such that process 1600 decision Lock 1670 routes execution, via NO path 1672, 
remains in its initial state until such time as a user has 10 back to block 1660 to continue the upgrade. Alternatively, if 
invoked a firmware upgrade process. the upgrade has been completed, then decision block 1670 

Alternatively, if the user has just invoked a firmware routes execution, via YES path 1676, back to block 1610 

upgrade, then decision block 1620 routes execution, via YES which, in turn, sets process 402 back to its initial state, which 

path 1626, to start the firmware upgrade process. As such, includes changing the mode of the flash memory back to 

process 402 enters an upgrade state. Execution proceeds to 15 read-only 

block 1628 which first reads the 32-bit value of the key Possible errant operations are shown as dashed lines in 

stored in its original location in flash memory and writes that FIG. 16. Given the very short time, associated with an 

value into the write access key register. Thereafter, block upgrade interval, generally a few minutes, if not less, then if 

1628 resets and starts a software-implemented timer, Le., a an errant operation were to occur, in all likelihood, it would 

firmware upgrade timer illustratively five minutes in dura- 20 occur while process 402 was in its initial state. As noted 

tion. Once a firmware upgrade process has been invoked, the above, in this state the contents of the write access key 

upgrade, if it is to occur, must start within this interval. If a register are cleared, i.e., zero, meaning that the key stored 

flash write request does not arise within this interval, then therein is not defined at this time. Hence, a random attempt 

the firmware upgrade process is terminated with process 402 that might arise to simply write data into flash memory 376, 

returning to its initial state; thereby requiring the. user to 25 while process 402 is in its initial state, is symbolized by 

re-invoke the upgrade process should (s)he desire to proceed dashed line 1690. Inasmuch as the flash memory is then set 

with an upgrade. to its read-only state, any errant attempt to write into it 

Decision blocks 1630 and 1640 determine whether a flash would generate, as symbolized by block 1695, a system 

write request occurs within this timing interval. In particular, check exception after which execution would effectively exit 

decision block 1630 tests whether a flash write request was 30 from process 402. The occurrence of such an exception 

received from a host on the LAN or a remote client- This would simply cause operating system 4010 (see FIG. 4A) to 

request results from a process executing at the file server initiate a complete reset of the LAN modem, 

that, with an exception of responding to a request from the A different errant attempt, as symbolized by dashed line 

Configuration Manager to initiate the upgrade process, is 1680, might occur to change the mode of the flash memory 

otherwise totally independent from firmware upgrade pro- 35 from read-only to read/write, inasmuch as the mode of the 

cess 402. Hence, for a mode change to occur, two indepen- flash memory will be read-only, immediately before the time 

dent events must coincide: a firmware upgrade must be this attempt occurred, then the contents of the write access 

initiated by the Configuration Manager, thereby changing key register will then be zero, meaning that: the key stored 

the state of process 402 and, in response to a request from therein is not yet then defined. Hence, this errant operation 

the Configuration Manager, the remote file server must 40 would need to change the contents of the write access key 

generate a flash write request. The necessary coincidence of register to identically match the 32-bit key as stored in its 

these two, otherwise independent events, further decreases original location in the flash memory before the mode of the 

the likelihood, quite substantially, that the mode of the flash flash memory could change to read/write. Consequently, 

memory might change to read/write as a result of an errant since, in all practical likelihood, the zero contents of the 

program execution in DRAM 372 (see FIG. 3). In any event, 45 write access key register do not match the actual key in its 

if such a flash write request was not received, then decision original location in the flash memory, any change in the 

bock 1630, shown in FIG. 16, routes execution, via NO path mode of the flash memory will be blocked, as symbolized by 

1632, to decision block 1640. This latter block tests whether dashed line NO path 1686 emanating from decision block 

the firmware upgrade interval has expired. If the interval has 1685, resulting, should a write operation then errantly occur, 

not yet elapsed, then decision block 1640 feeds execution 50 in a system check exception. The mode of the flash memory 

back, via NO path 1642, to decision block 1630 to again test would only change if the key were to become defined, Le., 

for a flash write request, and so forth. Alternatively, if this if and only if the value then stored in the write access key 

timing interval has elapsed, then decision block 1640 routes register were to identically match the key stored in its 

execution, via YES path 1646 and path 1676, back to block original location in the flash memory. Hence, if such an 

1610 to reset process 402 to its initial state. 55 errant write request were to occur, then this attempt would 

However, when a flash write request is received during the need to set, in some fashion, the contents of the write access 

timing interval, decision block 1630 then routes execution, key register to exactly match that of the actual 32^bit key 

via YES path 1636, to decision block 1650. Thus latter stored in its original location in the flash memory. While 

decision block determines whether the key has been defined, such an occurrence, strictly speaking, is not impossible, the 

Le., whether the value of the key stored in the write access 60 likelihood that an errant condition would occur that sets the 

key register exactly matches the value of the key as currently contents of a particular 32-bit register to match a predefined 

stored in its original location in flash memory. If the key is random or pseudo-random 32-bit value, this result being 

not defined, then decision block 1650 routes execution, via symbolized by dashed line YES path 1688 emanating from 

NO path 1652 to trap this error condition and generate a decision block 1685, is extremely unlikely, in the range of 

system check exception. Alternatively, if the key is defined, 65 less than one in a billion. 

Le. the value in the write access key register identically FIG. 17 depicts a flowchart of Firmware Assurance Man- 
matches the value of the 32-bit key in its original location in ager process 1700. As discussed above, this process is a 
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preemptable background - process, executing with, e.g., a from a predefined stored web page templates by selectively 

lowest execution priority, that continually compares the inserting, e.g., event-specific code segments therein, 

entire executable program code stored in DRAM, on a Illustratively, this insertion is accomplished by substituting 

location-by-location basis, with that stored in the flash such a segment(s) for a corresponding so -called 

memory to assure integrity of the former. In the event a 5 "placeholders)" situated in the template. These segments 

discrepancy is detected, process 1700 copies the contents of can each represent an HTML form component or form, an 

as many locations in the flash memory to corresponding HTML directive, e.g., <META H IT KEQUIV="Re fresh" 

locations in the DRAM that are necessary to eliminate the CONTENT=5>, a dialog box, a graphic, a predefined textual 

discrepancy. message or, generically speaking, any object (or its file 

Specifically, upon entry into this process, execution first 10 name), including, e.g., an applet (such as a JAVA or JAVA- 

proceeds to block 1710. This block, when executed, initial- SCRIPT applet — "JAVA" and "JAVASCRIPT" being trade- 

izes a flash pointer (FLASH PTR) and a DRAM pointer marks of Sun Microsystems Inc. and Netscape Commum- 

(RAM_PTO) to rx)int to staitmg addresses of the executable cations Corporation, respectively, both of Mountain View, 
program code in both the flash memory and the DRAM, Calif.), an audio or a video object, whether implemented 
respectively. Thereafter, execution proceeds to decision is through HTML or otherwise, that is to be selectively: (a) 
block 1720 which tests whether Firmware Upgrade process presented, through direct insertion of object code into the 
1600 (see FIG. 16) is in its upgrade state, i.e., whether an document, to a user; (b) accessed to yield a file containing 
upgrade is expected to occur within illustratively five min- an object which is subsequently assembled into the docu- 
utes or is then occurring. Inasmuch as upgraded code is ment by the browser for display to the user; or (c) executed 
written directly into flash memory, discrepancies will cer- 20 at that workstation to, e.g., generate a particular display, 
tainly arise between the upgraded program code then stored invoke a particular procedure thereat, and/or to solicit a 
in flash and a prior version then stored in DRAM; hence, all response, such as an item of data or a selection among a list 
error checking undertaken by process 1700 is suspended of predefined data values, from the user. Since relatively 
with execution simply exiting at this point from this process. few, if any, full web pages are stored, memory requirements 
Once the upgrade is complete, the Configuration Manager 25 become rather modest. Such web pages are used for query- 
will reset the LAN modem to transfer the upgraded code ing a user stationed at a workstation to enter information 
from the flash memory into the DRAM, and will then restart needed to configure the LAN modem, as well as for dis- 
Firmware Assurance Manager process 1700. playing the specific nature and cause, if known, of a detected 

Alternatively, if a firmware upgrade is not then occurring fault condition so that the user situated at a host can take 

or expected to occur within its five minute window, i.e., 30 appropriate action. As any one skilled in the art can readily 

process 1600 is in its initial state, then, as shown in FIG. 17, appreciate, the inventive concept of dynamic web page 

execution proceeds, via NO path 1726 emanating from creation using selective insertion of web page components) 

decision block 1720, to decision block 1730. This latter into a predefined page template has extremely wide 

decision block determines whether the contents of the flash applicability, clearly well beyond that of use with just a LAN 

memory at an address specified by the current value of the 35 modem, that encompasses nearly any environment that 

flash pointer are identical to the contents of the DRAM at an utilizes web pages. Such an environment can certainly 

address specified by the current value of the DRAM pointer. include client-server usage over the Internet and/or an 

If no such discrepancy exists, then decision block 1730 intra -net, or other networked environment 

routes execution, via YES path 1736, to block 1750. FIG. 18 depicts a high-level block diagram of web server 

Alternatively, if a discrepancy between the contents of these 40 412 and certain of its associated processes. As shown, the 

two locations then exists, decision block 1730 routes web server contains Preprocessing operation 1810, Table 

execution, via NO path 1732, to block 1740. This latter 1820, Static Page Processing operation 1830, Dynamic Page 

block, when executed, copies the contents of the flash Formation operation 1840, Post Processing operation 1850 

memory at an address given by the current value of pointer and Repository 1860. Repository 1860 can store both static 

FLASH_PTR into the location in DRAM at an address 45 pages, i.e. complete web pages, and templates and pre- 

given by the value of pointer RAM PTR. Thereafter, defined web page components. To save storage space, the 

execution proceeds to block 1750. Block 1750, when repository, as specifically used in the LAN modem, stores 

executed, increments the values of each of the flash and templates and page components, rather than only full web 

DRAM pointers by one to point to the next location in both pages. 

the flash memory and the DRAM, respectively. Once — his 50 In particular, an incoming HTTP request, typically in the 

occurs, execution proceeds to decision block 1760 which form of a GET command, from a browser at a host on the 

tests whether an end of the executable program code stored LAN, as symbolized by line 1801, is routed through TCP/IP 

in the flash memory has been reached. If the end has not process 425 (and then through HTTP process 425 to web 

been reached, decision block 1760 routes execution, via NO server 412. Though commands and files transiting between 

path 1762, back to block 1720 to test whether a firmware 55 TCP/IP process 425 and web server 412 flow through HTTP 

upgrade is now occurring or about to occur, and so on. server 415 (see FIG. 4B) for suitable encapsulation into arid 

Alternatively, if the end of the executable code in flash extraction from IP packets, for the purposes of 

memory has been reached, then decision block 1760 routes simplification, the operations involving server 415 (as well 

execution, via YES path 1766, back to block 1710 to reset as the server itself) have all been purposely omitted from 

the flash and DRAM pointers to point to the starting address 60 FIG. 18 and the following discussion. In response to this 

of the executable program code flash and DRAM, request, Preprocessing operation 1810, shown in FIG. 18, 

respectively, and so forth. checks the request for proper security clearance and, if the 

e. Internal web server and dynamic web page construction user has proper privileges to access the page he(she) desires, 

using web page templates then accesses table 1820 to ascertain the related handling 

As discussed above, the inventive LAN modem utilizes 65 functions, either POST or SEND, for that page. If no entry 

an internal web server 412 (see FIG. 4B) that, in addition to for that page exists, then the page is a static page, i.e. having 

storing full web pages, constructs web pages in real-time no changing components and hence the page itself requires 
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do processing other than to access it from the repository. The GET commands. In response, Dynamic Page Formation 

SEND function specifies that the server will access a desired operation 1840 accesses and then downloads each compo- 

page, including dynamically constructing the page as nent from repository 1860 and supplies that component, in 

needed, and send that page back to the requesting host. The a separate file, to TCP/IP process 425 for eventual routing to 

POST function, in contrast, accepts data as entered from the 5 the workstation on the LAN. 

user, in response to e.g., a currently displayed web page, and If, alternatively, the handling function is a POST function, 

requests that the web server process the data as appropriate. then, as symbolized by line 1826, Post Processing operation 

Should the desired page be a static page, then, as symbolized 1850, obtains the data, supplied by the user at a workstation 

by line 1822, Static Page Processing operation 1830, which on the LAN and in response to a currently displayed page 

is discussed in detail below in conjunction with FIG. 19, 10 associated with, e.g. ISP Wizard 1880 or SPID Wizard 1890, 

then accesses, as symbolized by line 1835, that page in its and attempts, as symbolized by line 1852, to update asso- 

entirety from repository I860. In response, repository 1860 ciated configuration data stored in memory 370, such as in 

supplies a file containing the HTML contents for that page. Profiles Data Base 1870. Based on the validity of the data 

This file is then applied, as symbolized by line 1866, to received from the user and the success or failure of the 

TCP/IP process 425 for routing to the requesting workstation is update, Post Processing operation 1850 accesses an associ- 

for display. The page content in the file, in turn, will specify ated template stored in repository 1860 and inserts appro- 

a name of each additional file that represents an object that priate page components based on and to indicate the success 

forms part of the displayed page. The browser, executing at or failure of the update. The resulting dynamically created 

the requesting workstation, then issues a GET command for page is then sent, as a file, to TCP/IP process 425 for routing 

each additional file specified in the page; then, as the files are 20 to the appropriate workstation on the LAN. 

received, properly assembles the page, including its objects; FIG. 19 depicts a flowchart of Static Page Processing 

and finally displays the complete page to the user. operation 1830. As noted above, this operation accesses and 

If, however, table 1820 has handling function entries, downloads a static web page from repository 1860. 
SEND and/or POST, for the requested page, then the In particular, upon entry into operation 1830, execution 
requested page needs to be dynamically constructed. In this 25 first proceeds to step 1910. This step, when performed, 
case, the requested page must be constructed from a stored obtains an incoming GET command from a browser execut- 
template; hence necessitating additional page processing. ing on a workstation situated on the LAN. To simplify the 
Specifically, if the handling function specified in table 1820 discussion, assume that a browser requests a web page 
is a SEND function, then dynamic Page Formation operation containing a document named "Manual. I ITM". Once this 
1840 first accesses the page template and specific data 30 GET command is received, then step 1920 accesses, as 
regarding the status and state of the LAN modem. This data symbolized by line 1922, table 1820 to determine whether 
is used, by Dynamic Page Formation operation 1840, to the requested document is one requiring further processing 
specify the page components that will be dynamically prior to its transmission to the requesting workstation. If the 
inserted into the template. In general, this data collectively document requires such processing, an entry will exist in 
includes the value of various shared (global) variables as 35 Table 1820, containing illustrative entries 1925, for that 
well as appropriate entries from Host list 1300 and Network document and associated handling functions that, when 
Service Provider list 1350 (both of which are collectively called, implement the necessary processing. Inasmuch as 
shown as Profiles Data Base 1870). The specific items of document "Manual.HTM" is static, i.e. it is stored in its 
data that are requested in any one instance are defined by entirety in the repository, no such entry exists for it in the 
then executing procedure for which web pages are being 40 table. As such, once an access operation is performed into 
displayed by the LAN modem, such as, e.g., ISP Wizard Table 1820 with the results re turned, then, as symbolized by 
1880 (which simplifies set-up of network parameters for an line 1926, step 1930 is performed to access, as symbolized 
Internet service provider, including user account and by line 1932, that document within repository 1860. Inas- 
password, and displays appropriate network error messages much as the repository contains an entry for this document, 
associated therewith) or SPID Wizard 1890 (which, as 45 i.e. MANUAL _HTM, stored HTML code for the corre- 
discussed above, simplifies ISDN configuration of the LAN sponding document is then accessed from the repository, as 
modem by automatically setting the SPIDs in the LAN symbolized by line 1936, and sent, as a complete file, 
modem to those associated with the ISDN lines then con- through step 1940, via TCP/IP process 425 (see FIG. 18), to 
nected to the LAN modem); the underlying executable code the browser which requested that document. Thereafter, 
for both of these procedures is stored within memory 370. 50 execution exits from procedure 1830. Inasmuch as the 
Once the data pertinent to the requested page is obtained, as statically constructed document likely contains names for 
symbolized by line 1875, operation 1840 accesses the cor- other page components, the browser will request each one of 
responding web page components), as specified by the these corresponding components, in seriatim, from server 
value of each data item, and inserts that component into the 412 for page assembly and eventual display, 
appropriate location within the code for the template by 55 FIG. 20 depicts a flowchart of Dynamic Page Formation 
substituting the code for that segment for a corresponding operation 1840. As noted above, this operation dynamically 
"placeholder" in the template, as will be discussed in detail constructs a web page given a template and associated page 
below in conjunction with FIGS. 22-26. Thereafter, components accessed from repository 1860, and then down- 
dynamic page formation operation 1840, shown in FIG. 18, loads the resulting page to a requesting browser, 
supplies, as symbolized by line 1846, a file containing the 60 In particular, upon entry into operation 1840, execution 
dynamically constructed page, i.e. the template with substi- first proceeds to step 2010. This step, when performed, 
tuted components therein, to TCP/IP process 425 for routing obtains an incoming GET command from a browser execut- 
to the requesting workstation on the LAN. As with a static ing on a workstation situated on the LAN. To simplify the 
page, the dynamic page will likely contain file names discussion, assume that a browser requests a web page 
containing code associated with one or more of its compo- 65 containing a document named "lan .HTM". Once this GET 
nents which the browser, in rum, will request, in seriatim, command is received, then step 2020 accesses, as symbol- 
from web server 412, through issuance of an appropriate ized by line 2022, table 1820 to determine whether the 
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requested document is one that requires further processing named in the POST command, and to which the workstation 
prior to its transmission to the requesting workstation. If the is responding, is one that requires further processing. If the 
document requires such processing, an entry will exist in document requires such processing, an entry will exist in 
Table 1820 for that document and associated handling Table 1820 for this document and associated handling 
functions that, when called, implement the necessary pro- 5 functions that, when called, provide the necessary process- 
cess in g. Since the document will be dynamically ing. Since processing is required, here in the form of 
Constructed, additional processing will be required, i.e. to updating profile information stored at the LAN modem, 
construct the document Hence, an entry will exist for this Table 1820 will contain the specific POST function call 
document within table 1820. In this case, access into the needed to implement the processing associated with this 
table, as symbolized by line 2026, results, through step 10 document. In this case, access into the table, as symbolized 
2030, in an entry, for this document, illustratively containing by line 2126, results, through step 2130, in an entry, for this 
a specific SEND function call. As such, once the access document, illustratively containing a specific POST func- 
completes and the SEND handling function is found for this tion. As such, once the access completes and the POST 
document, as symbolized by step 2030, step 2040 is per- handling function is found for this document, as symbolized 
formed. Step 2040, when performed, invokes the specific 15 by step 2130, step 2140 is performed. Step 2140, when 
SEND function call, specified in the entry, to properly performed, calls the specific POST function, specified in the 
process the code for the document in order to dynamically entry, to properly process the response which the user has 
create the desired web page. In particular, step 2040 accesses provided for this document. In particular, step 2140, checks 
the template web page from repository 1860, here under the the validity of the user-supplied data, and if valid, updates, 
entry "LAN _HTM". Step 2040 also accesses relevant data 20 as symbolized by line 2146, the corresponding profile, e.g. 
stored in Profile Data Base 1870 (containing, as noted an entry in either Host list 1300 or Network Service Provider 
above, Host list 1300, as a LAN Profile, and Network list 1350, with the data provided by the user and contained 
Service Provider list 1350, as a WAN Profile). In addition, in the POST command. Thereafter, step 2140, based on the 
step 2040 also reads appropriate shared (global) variables, as validity of the data received from the user and the success or 
well as system state and status information. As discussed, 25 failure of the update, accesses, as symbolized by line 2142, 
the specific items of data retrieved by step 2040 is specified an associated template along with appropriate page compo- 
by the state of the particular procedure then being executed, nents from repository 1860. Step 2140 then substitutes the 
e.g., ISP Wizard 1880 or SPID Wizard 1890 (see FIG. 18). page components into the template to create a dynamic page 
Once the necessary template and data have all be accessed, that is based on and indicates the success or failure of the 
step 2040, shown in FIG. 20, utilizes the data to select the 30 update. Step 2150 then sends the resulting dynamically 
appropriate web page components from repository 1860 that created page, as a single file, to TCP/IP process 425 (see 
are to be substituted into the template in place of cone- FIG. 18) for routing to the appropriate workstation on the 
sponding placeholders. Once the substitutions are completed LAN. Thereafter, as shown in FIG. 21, execution exits from 
thereby yielding a dynamically constructed page, a file operation 1850. 

containing the resulting page is sent, by step 2050, to the 35 To further illustrate the inventive dynamic web page 

requesting browser, via TCP/IP process 425 (see FIG. 18). construction, two examples, one being creation of a specific 

Thereafter, as shown in FIG. 20, execution exits from error message and the other being creation of a dynamically 

operation 1840. Inasmuch as the dynamically constructed changing progress bar display object will now be discussed, 

document likely contains names for other page components, First, consider FIG. 22 which depicts code 2200 for an 

the browser will request each one of these corresponding 40 illustrative inventive web page template. This template 

components, in seriatim, from server 412 for page assembly forms a basis of several web pages that are used in con- 

and eventual display. junction with ISP Wizard 1890 (see FIG. 18) for use in 

FIG. 21 depicts a flowchart of Post Processing operation configuring LAN network parameters for the LAN modem. 
1850 that is also performed by web server 412. As noted This code contains conventional HTML code, and place- 
above, Post Processing operation 1850 obtains data, sup- 45 holders 2210, 2215, 2220, 2225, 2230, and 22302, and 2235 

plied by the user at a workstation on the LAN and in containing code terms _REFRESH , TITLE , 

response to a currendy displayed page associated with, e.g. _PICTURE1_, _TEXT1 PICTURE2_, _TEXT2_, 

ISP Wizard 1880 or SPID Wizard 1890, and attempts to _PICTURE2_ and _BUTTON_. Based on the state and 

update associated configuration data stored in memory 370, status of the system, and/or values of shared (global) 

such as in Profiles Data Base 1870. Based on the validity of 50 variables) at the time a dynamic page is created from this 

the data received from the user and the success or failure of template, specific page components, such as particular 

the update, operation 1850 will access an associated static refresh time commands, text and pictures will be selectively 

page stored in the repository or create one dynamically to substituted for the corresponding placeholders) to create a 

indicate the success or failure of the update, and then send dynamic web page. The template, as rendered by a web 

that page to the appropriate workstation, on the LAN, for 55 browser on a display screen, would appear as shown in FIG. 

local display thereat. 23. Each of the placeholders merely appears as a textual 

Specifically, upon entry into operation 1850, execution object set off by underscores in a predefined location, as 

first proceeds to step 2110. This step, when performed, speci fied by HTML coding within code 2200 shown in FIG. 

obtains a POST command from a browser executing on a 22. 

workstation situated on the LAN. To simplify the discussion, 60 Given web page template 2200, FIG. 24 depicts, in 

assume that a browser generates this command to provide high-level block diagram form, inventive process 2400 for 

specific user-supplied data requested by document dynamically forming a web page, such as for the ISP Wizard, 

"wan .htm". The POST command will contain the document using this template and predefined web page components, 

name, here "wan.htm", and appropriate identifiers) each In particular, first as shown in block 2410, ISP Wizard 

with an item of user-supplied data. Once this POST com- 65 1880 (see FIG. 18) is initiated. During the course of execut- 

mand is received, then step 2120 accesses, as symbolized by ing this wizard, the status of the configuration process, 

line 2122, table 1820 to determine whether the document particularly responses from the ISP or network, are used to 
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set global variables to indicate success or*a specific failure* ~ 
condition. During the course of executing this Wizard, a 
series of web pages are dynamically constructed and dis- 
played to the user, with the particular pages varying based on 
the then current state of the Wizard. For example, assume 5 
that a user entered an incorrect telephone number into the 
Wizard causing a logon placed through the LAN modem to 
that ISP to fail; hence representing a specific error condition. 
This error condition, reflected in values of various global 
variables, results in the selection, as defined in the program 1Q 
code for the ISP Wizard, of particular page objects, as 
delineated in block 2420, for each of the placeholders in 
template 2200. Template 2200 is accessed, as symbolized by 
block 2430 and applied along with the specific page com- 
ponents for the placeholders, as denned by block 2420, to 
block 2440. Block 2440 substitutes each of the specific 15 
objects defined in block 2420 for the corresponding place- 
holder in template 2200. For example, the two placeholders, 
2230j and 2230 2 , (see FIGS. 22 and 23) which represent a 
common picture but in two separate locations, are each 
replaced by HTML code for a graphic of a flashing red ball. 20 

An unused placeholder, i.e. REFRESH , is removed 

inasmuch as the resulting web page does not generate an 
update request to the server but it is displayed constantly 
while awaiting a response from the user. The resulting 
HTML code for the dynamic web page is shown as code 25 
2500 in FIG. 25. Comparing this code with template code 
2200 shown in FIG. 22 reveals that appropriate HTML code 
has been substituted for each of the corresponding place- 
holders. For example, the placeholders _TTTLE__ and 
_TEXT1_ have been replaced by "ISP Wizard" and "Log- 30 
ging on the ISP Failed!", respectively. The resulting 
dynamic web page as rendered on a display screen by a 
browser, in response to code 2500, would appear as page 
display 2600 shown in FIG. 26. For a different error con- 
dition or a successful logon attempt, the values of the global 35 
variables would change accordingly from those associated 
with the selected page components shown in block 2420 in 
FIG. 24. Hence, different predefined page components 
would be dynamically substituted into template 2200 to 
produce a web page that, when rendered on the display 40 
screen at the workstation, would indicate the particular result 
which then occurred, i.e. this different error condition or a 
successful logon. 

Consider, as a second example and as illustrated in FIG. 
27, the dynamic construction of successive web pages that 45 
collectively implement a dynamically changing progress bar 
object. Here, the progress bar consists of a sequence of dots 
that grows by one dot every three seconds to chart progress 
of a given item. Illustratively, the item being charted is 
progress of loading the code for the ISP Wizard, for subse- 50 
quent execution. This code includes a single web page file 
(including a page template and all associated predefined 
page components) and executable code, and is loaded both 
in object code, from flash memory 376 into DRAM 372 (see 
FIG. 3) once a user has manually initiated this Wizard during ^ 
configuration. The progress bar is rendered by a dynamically 
changing HTML document (web page) that changes at set 
three-second intervals. This page is generated by 
substituting, with each new request generated by the 
browser at three-second intervals, page components 2720 lT 
2720 2 and 2720 3 (see FIG. 27), into page template 2200 to 60 
yield correspondingly rendered web pages 2710 containing 
web pages 27101, 27102 and 27103, respectively. Here, 
appropriate global variables are set to reflect a current status 
of the Wizard, which through a software timer, changes 
every three seconds during a loading process. This status 65 
change results in the textual component for placeholder 
_Text2__ being dynamically changed by replacing it with 
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different HTML commands, i.e. here having an* additional 
HTML "DOT" instruction (which, when rendered by a 
browser, results in display of another successive circular 
dot). 

The discussion will now address the manner through 
which a web page template, associated web page 
components, and appropriate executable code is collectively 
stored as a single module within memory 370 of the LAN 
modem for use by web server 412 (see FIGS. 3 and 4B). 
Since this module is initially stored in flash memory 376 and 
subsequently copied, with the same data structure, into 
DRAM 372 for subsequent execution, the discussion will 
merely refer to this module as being stored within memory 
370. 

FIG. 28 depicts a flowchart of File Creation process 2800 
that creates a common file of a web page lemplate(s) and 
associated web page components. This process is executed 
off-line in a computer to generate a file that is then integrated 
and linked to the executable code for, e.g., the ISP Wizard, 
and then appropriately compiled to form a module which, in 
turn, is subsequently loaded during, e.g., manufacture (or 
during an upgrade operation) into memory 370 and specifi- 
cally to form repository 1860 (see FIG. 18). Prior to execut- 
ing this process, a separate source file for each web page 
template and other source files, each containing a web page 
component associated with that particular template, is stored 
into a common directory on that computer. 

Upon entry into process 2800, block 2810 is first 
executed. This block searches a common directory, that 
contains all the web page component and template files, for 
all those files that contain web page components. These flies 
are typically identified by their extension; namely, .HTM or 
.HTML for HTML files, JPG or .GIF for image files, Ml 
for audio files and so forth for all other suitable file types. 
Once these files are found and suitably catalogued into a set, 
block 2815 executes to select, as a current file to process, a 
first file in the set. Thereafter, a loop is entered consisting of 
blocks 2820-2840 to integrate each file in the set into a 
resulting common module. In particular, within this loop, 
block 2820 is first executed to compute a length of the 
current file and, from its extension, a corresponding file type. 
Thereafter, block 2825 executes to form a header for the 
current file, which includes the length of this file, an iden- 
tification of a server on which the file is stored, a date and 
version number of this file and other pertinent information. 
Once formed, the header is then prepended to the current 
file. Execution then proceeds to block 2830 which creates a 
separate document array and copies the contents of the 
current file, including its prepended header, into that array. 
Each such document array only stores one web page com- 
ponent and its prepended header. Once block 2830 com- 
pletes its execution, decision block 2835 determines whether 
all the files in the set have been processed. If another file 
remains to be processed, then decision block 2835 routes 
execution, via NO path 2836, to block 2840 to select a next 
successive file remaining to be processed in the set. 
Thereafter, execution loops back, via path 2843, to block 
2820 to process, that next file, and so forth. 

If, however, all the files in the set have been processed, 
then decision block 2835 routes execution, via YES path 
2838, to block 2845. This latter block, when executed, 
creates a source file, illustratively named "bsource.c", and 
stores all the document arrays into that file. A definition of 
the resulting data structure that is to store pointers to the 
page templates) and associated web page component is 
generated and stored in this source file. Thereafter, execution 
proceeds to block 2850 which includes in this source file, a 
list of pair entries, specifically data structure 3000 (to be 
discussed below in conjunction with FIGS. 29-31) which 
contains a pair entry for each document array. Each such pair 
consists of a name of the array and a pointer to its starting 
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location in the memory; the -actual values of the pointers will- 
be set once the module is appropriately linked. Through this 
list, each array component in the repository can be readily 
located by its name. Once this list is fabricated, block 2855 
executes to create a header file that declares all document 
arrays as externals for use during subsequent compilation. 
At this point, one source file, i.e. bsource.c, containing a list 
of all the document arrays for both the web page templates 
and web page components, and those arrays themselves has 
been created. Execution then exits from process 2800. 
Thereafter, this single file is then compiled along with the 
executable source code. The resulting code is then linked 
together, through a conventional linker, to form the single 
module. This module is then subsequently stored within 
memory 370. 

FIG. 29 depicts data structure 3000 that houses the list of 
paired entries and document arrays 2930 for the web page 
templates and associated web page components, and which 
is stored within the repository in memory 370. As shown, 
data structure 3000 contains a list of paired entries, i.e. 
effectively forming two columns 2910 and 2920, with each 
such pair containing, in separate fields, of which 2910 2 and 
2920j are illustrative, a name, e.g. NAMEj, NAME2, - . . , 
of a document array and a pointer, e.g. POINTER^ 
POINTER 2 , . . . , which specifies a starting location, as 
symbolized by lines 2925j, 2925^ . . . , within memory 370 
at which that particular array, e.g. 2930 1? 2930 2 , . . . , is 
stored. An illustrative actual source listing of data structure 
3000 as used by web server 412 in the LAN modem is 
depicted in FIGS. 30A and 30B; for which the correct 
alignment of the drawing sheets for these two figures is 
shown in FIG. 30. Each paired entry in data structure 
identifies an array containing either a template or a web page 
component, with the paired entry containing a pointer fol- 
lowed by a file name. FIG. 31 depicts actual object code of 
an illustrative web pages component, i.e. FRMAEN_HTM 
[], as it would be stored within the repository. 

Though the inventive dynamic web page creation process 
has been described, in conjunction with the preferred 
embodiment of the LAN modem, as selecting particular web 
page components for insertion into a template web page 
based on particular error conditions, and/or system state or 
status information, those skilled in the art will clearly realize 
that, generally speaking, any input criteria can be used 
instead, as determined by the needs of a particular applica- 
tion for which dynamic page creation is to be used, to select 
which particular page components to use in any given 
instance and insert into an associated page template, from 
amongst all those then stored. 

Furthermore, even though the inventive apparatus has 
been specifically described in the context of providing a 
4-port Ethernet bub and associated network functionality, 
e.g., domain name resolution and DHCP handling, for 
accommodating four separate local hosts, the apparatus can 
be easily expanded, in a manner readily apparent to anyone 
skilled in the art, to accommodate any number of hosts by, 
e.g., suitably enlarging both the hub and various routing 
tables and lists, some of those modifications having been 
discussed above, as well as storing additional configuration 
information, such as user profiles, as needed. 

Moreover, though configuration of the LAN modem has 
been described above in terms of communicating with an 
executing web browser in a workstation connected to the 
LAN modem, other appropriate TCP applications executing 
at the workstation and capable of conducting interactive 
communication with a server in the LAN modem and a user 
at the workstation, such as Telnet can be employed instead. 
Similarly, such applications can also be used in conjunction 
with interception of DNS Request (or other appropriate) 
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messages tovcigv, a remote server, that would occur during 
TCP applications other than web browsing, to display appro- 
priate fault messages. 

Although a single, though rather detailed, embodiment 
which incorporates the teachings of the present invention 
has been shown and described in detail herein, those skilled 
in the art can readily devise many other embodiments that 
still utilize these teachings. 

We claim: 

1. Apparatus for a network communication device com- 
prising: 

a processor; 

a memory, connected to the processor, for storing execut- 
able instructions therein; and 

communication circuitry, connected to and controlled by 
the processor, for establishing a communicative con- 
nection between a first network and, via a second 
network, to at least one host device connected to the 
second network; 

wherein, in response to the executable instructions and a 
failure of a network connection for the one host 
between the network communication device and the 
first network, the processor 

in response to receipt, from the one host device, of a 
DNS query message destined, through the network 
communication device, for the first network, request- 
ing identification of a domains name system (DNS) 
server residing on the first network for providing 
translation of a domain name of an associated server 
accessible through the first network to a network 
address corresponding to the associated server, inter- 
cepts the query message to yield an intercepted query 
message and issues, in response to the intercepted 
query message, a DNS reply message, back to the 
one host device, wherein the DNS reply message 
specifies, to the one host device and as the network 
address of the DNS server, a network address asso- 
ciated with the network communication device; 

in response to a DNS request message, issued by the 
one host device, to translate the domain name into 
the network address corresponding to the associated 
server, the DNS request message containing the 
network address of the network communication 
device supplied in the DNS reply message as the 
network address of the DNS server, supplies a DNS 
response message containing, as a translated network 
address for the domain name, the network address of 
the network communication device in lieu of the 
network address of the particular server; and 

in response to a download request from the host to 
download a default web page residing at a server 
having the network address specified in the DNS 
response message, the download request specifying 
the network address of the network communications 
device as the translated network address provided in 
the DNS response message, downloads, from a 
server in the network communication device, a web 
page containing failure information, to an applica- 
tion executing at the one host device, wherein the 
web page specifies a particular fault condition that 
caused the failure of the network connection so as to 
provide an indication to a user at the one host device 
of the cause of the failure. 

2. The apparatus in claim 1 wherein the first and second 
networks comprise a remote network and a local area 
network (LAN), respectively. 

3. The apparatus in claim 2 wherein the application 
comprises a web browser and the failure information visu- 
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ally indicates the particular fault condition; through the web 
browser, to the user stationed at the one host device. 

4. The apparatus in claim 3 wherein the processor, in 
response to the stored instructions, downloads, through an 
hypertext transport protocol (HTTP) server executing in the 
network communication device, the web page correspond- 
ing to the fault condition in lieu of a default web page 
requested by the one host device. 

5. The apparatus in claim 4 wherein the processor, in 
response to the stored instructions, dynamically constructs 
the web page. 

6. The apparatus in claim 5 wherein the DNS query, DNS 
request and DNS response messages all appear on the LAN. 

7. The apparatus in claim 5 wherein the processor, in 
response to the stored instructions, constructs the web page 
by dynamically inserting error-specific web page 
components, as specified by the fault condition, into a web 
page template so as to yield a complete web page. 

8. The apparatus in claim 7 wherein each of the web page 
components is inserted into the page template in lieu of a 
corresponding pre-defined placeholder located in the tem- 
plate. 

9. The apparatus in claim 8 wherein the processor, 
in response to the failure condition: 

detects the fault condition so as to yield a detected fault 
condition; and 

sets, in response to the detected fault condition, a 
variable to a value that corresponds to the detected 
failure condition; and 
in response to the request message: 

reads the value of the variable; 

constructs the web page by inserting the web page 
components corresponding to the value of the vari- 
able into the page template so as to form the com- 
plete web page; and 

downloads the complete web page to the one host 
device. 

10. The apparatus in claim 9 wherein the DNS query, 
DNS request and DNS response messages all appear on the 
LAN. 

11. A method for use in a network communication device 
having a processor, a memory, connected to the processor, 
for storing executable instructions therein, and communica- 
tion circuitry, connected to and controlled by the processor, 
for establishing a communicative connection between a first 
network and, via a second network, to at least one host 
device connected to the second network, the method com- 
prising the steps, implemented through the executable 
instructions and responsive to a failure of a network con- 
nection for the one host between the network communica- 
tion device and the first network, of: 

in response to receipt, from the one host device, of a DNS 
query message destined, through the network commu- 
nication device, for the first network, requesting iden- 
tification of a domain name system (DNS) server 
residing on the first network for providing translation of 
a domain name of an associated server accessible 
through the first network to a network address corre- 
sponding to the associated server 
intercepting the query message to yield an intercepted 

query message; and 
issuing, in response to the intercepted query message, 
a DNS reply message, back to the one host device, 
wherein the DNS reply message specifies, to the one 
host device and as the network address of the DNS 
server, a network address associated with the net- 
work communication device; 
in response to a DNS request message, issued by the one 
host device, to translate the domain name into the 
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network address corresponding to the associated server, 
the DNS request message containing the network 
address of the network communication device supplied 
in the DNS reply message the network address of as the 
DNS server, supplying a DNS response message 
containing, as a translated network address for the 
domain name, the network address of the network 
communication device in lieu of the network address of 
the particular server; and 
in response to a download request from the host to 
download a default web page residing at a server 
having the network address specified in the DNS 
response message, the download request specifying the 
network address of the network communications 
device as the translated network address provided in the 
DNS response message, downloading, from a server in 
the network communication device, a web page con- 
taining failure information, to an application executing 
at the one host device, wherein the web page specifies 
a particular fault condition that caused the failure of the 
network connection so as to provide an indication to a 
user at the one host device of the cause of the failure. 

12. The method in claim 11 wherein the first and second 
networks comprise a remote network and a local area 
network (LAN), respectively. 

13. The method in claim 12 wherein the application 
comprises a web browser and the failure information visu- 
ally indicates the particular fault condition, through the web 
browser, to the user stationed at the one host device. 

14. The method in claim 13 wherein the downloading step 
comprises the step of downloading, through an hypertext 
transport protocol (HTTP) server executing in the network 
co mmuni cation device, the web page corresponding to the 
fault condition in lieu of a default web page requested by the 
one host device. 

15. The method in claim 14 further comprising the step of 
dynamically constructing the web page. 

16. The method in claim 15 wherein the DNS query, DNS 
request and DNS response messages all appear on the LAN. 

17. The method in claim 15 wherein the dynamic con- 
structing step comprises the step of constructing the web 
page by dynamically inserting error-specific web page 
components, as specified by the fault condition, into a web 
page template so as to yield a complete web page. 

18. The method in claim 17 wherein the dynamic inserting 
step comprises the step of inserting each of the web page 
components into the page template in lieu of a correspond- 
ing pre-defined placeholder located in the template. 

19. The method in claim 18 further comprising the steps 

of: 

in response to the failure condition: 

detecting the fault condition so as to yield a detected 
fault condition; and 

setting, in response to the detected fault condition, a 
variable to a value that corresponds to the detected 
failure condition; and 
in response to the request message: 

reading the value of the variable; 

constructing the web page by inserting the web page 
components corresponding to the value of the vari- 
able into the page template so as to form the com- 
plete web page; and 

downloading the complete web page to the one host 
device. 

20. The method in claim 19 wherein the DNS query, DNS 
request and DNS response messages all appear on the LAN. 



